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IP^WTIFYTNO , H&HftSHEL &SSESSIMS *wn i^^rr ^ TT AT , 

OBJECTS AND A S SQCT &TE!n pr^S AMn p^^ 
Background 

' This is a continuation-in-part of United States 

Patent Application Serial Number 08/142,161, filed 
October 22, 1993. 

This invention relates to digital objects and 
associated rights and payments. 

By a -digital object- we broadly mean any set of 
sequences of bits or digits and an associated unique 
identifier which we call a "handle-, a digital object 
may incorporate information or material in which rights 
(e.g. , copyright rights) or other interests are or may be 
claimed. There may also be rights associated with the 
digital object itself. Thus digital objects may include 
conventional digital representations of works (books, 
papers, images, sounds, software) , and more broadly any 
digital material which is capable of producing desired 
manifestations for a computer user. Thus, a digital 
object could include programs and data which, though not 
directly a representation of the text of a work, enable 
the delivery over a network and the subsequent 
reproduction on a computer screen of selected portions of 
the text of the work. By the notion of rights which are 
or may be claimed in a digital object, we mean rights 
which exist under statute (e.g., copyright, patent, trade 
secret, trademark), or as a result of private action 
(e.g., via secrecy, cooperative ventures, or 
negotiation) . 

Rights are normally protected under the law by 
mechanisms that are paper-based. Patent and trademark 
applications are prosecuted by exchanges of paper with 
the Patent and Trademark office. Trade secret rights are 
often protected by appropriate legends on paper, and by 
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Physically guarding paper copies against disclosure 
Registration of claims in copyright is largely based on a 
paper system. Registration systems generally involve 
providing physical copies (sometimes, voluminous) to the 
i registering authority of the object to be registered. 

Holders of rights may get value from those rights 
by allowing others to copy, use, or perform the object 
covered by the rights in exchange for consideration 
(e.g., a photographer may sell copies of his 
photographs), m some situations there may no need for 
negotiation of the terms, which may be simple and well 
understood. The working out of compensation may be done 
automatically by private clearing house operations, such 
as the Copyright Clearance Center (as to photocopying, or 
ASCAP and BMI (in the music field). 

in other situations the rights holders may derive 
value by granting to others exclusive rights to 
disseminate the object in exchange for a royalty (e.g., a 
book author grants a publisher the North American 
paperback distribution rights) . Exclusive rights are 
typically subject to direct negotiation. 

It is common to provide for central registration 
of ownership and other exclusive rights so that others 
may know the timing and terms of those rights. 

Making digital objects available on networks 
(e.g., internet), gives rise to at least four specific 

TtT^ 0 V° nCern ' *** firSt iB toe e **« of movement 
of digital objects already contained in a computer 

network environment allowing the creation of multiple 

copies in multiple machines in fractions of a second 

The second is the importation of external information 

such as print material or isolated CD-ROM based material 

which must first be scanned or read into the system 

before it can be used. The third is export of internal 

network based information to paper using digital printers 
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or facsimile machines or copying to separable media such 
as tape or DAT for external transport to others. The 
fourth is that digital objects may be easily manipulated 
on a computer to produce derivative works. The 
derivative works can also be easily moved about in a 
computer network environment and be subject to further 
manipulation by other parties. Parallel and concurrent 
manipulation can generate an exponential proliferation of 
derivative works. 

Several technologies are known for handling 
privacy and authentication in a digital network 
environment, including public key cryptography, digital 
signatures, privacy enhanced mail, and notarization. 

Summary of the xir"»"«-1"n 
in general, in one aspect, the invention features 
a method of managing digital objects in a network, the 
objects are stored at locations accessible in the network 
using a storage technique which renders the digital 
objects secure against unauthorized access. Pointer 
information which associates each digital object 
identifier with a pointer indicating the location of the 
stored digital object is also stored in the network. For 
each digital object validation information is stored 
separately from the digital object, and is sufficient to 
permit a determination whether a purported instance of a 
digital object is identical to the original, in examples 
of the invention, an authorized user may have access to 
the validation information, using the digital object 
identifier, to determine whether a purported instance of 
a digital object is identical to the original. The 
validation information comprises a digital signature over 
the digital object. 

Another general aspect of the invention concerns 
managing reference information about digital objects in a 
network. The reference information is stored for each of 
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the digital objects. Validation information is also 
stored and is substantially smaller in size than the 
corresponding digital object. In examples of the 
invention, an authorised user may have access to the 
reference information using the unique identifier. The 
reference information includes information concerning at 
least one of the following: registration of rights in 
the digital object including performance of the object- 
accesses to and uses of digital object? the terms and ' 
conditions for use of digital objects; the ownership and 
transfer of rights to disseminate digital objects; links 
between different digital objects. 

In another general aspect of the invention, which 
concerns the storing of the digital objects in a network 
the verification information is stored separately from ' 
the digital object, in examples of this aspect of the 
invention, the pointer to the object (versus identifier 
xnformation for the object) is stored in multiple servers 
on the network. The identifiers are generated in a 
manner to distribute the pointer information with the 
unique identifier information) relatively evenly among 
the servers, using a hashing algorithm. 

Another general aspect of the invention concerns 
enabling users of a network to access or perform digital 
objects stored in the network. There are multiple 
pointer servers each of which accepts identifiers of a 
subset of the digital objects and returns corresponding 
pointers to the locations of the digital objects in the 
network. A directory server accepts identifiers of any 
of the digital objects and maintains and returns a table 
containing the locations of the pointer servers which 
accept those identifiers. 

Another general aspect of the invention concerns 
applying for registration of rights in digital objects by 
submitting to a registering authority an application for 



WO 97/43717 



PCT/US97/07834 



- 5 - 

registration of rights including the validation 
information and the unique identifier of a digital object 
and its properties. 

Another general aspect of the invention concerns 
i enabling holders of rights in digital objects to control 
terms and conditions under which they are accessed or 
performed by users in a network. Information is stored 
about terms and conditions for access to and performance 
of each digital object. The information is made 
available to a user in connection with a request for 
access to a digital object. The user is enabled to 
indicate assent to the terms and conditions. Access is 
permitted to the user only upon the user indicating 
assent to the terms and conditions. 

Another general aspect of the invention concerns 
enabling holders of rights in digital objects to control 
terms and conditions under which rights in the digital 
objects may be granted to others. Terms and conditions 
for the granting of rights is stored in the network. The 
terms and conditions are made available to potential 
rights holders upon request via the network. The 
potential rights holder and the current rights holder 
interact via the network to reach agreement on terms and 
conditions for grant of dissemination rights, 
information identifying grants of such rights for digital 
objects on the network are stored in a recordation server 
on the network. This will generally be part of the 
reference service. 

Another general aspect of the invention concerns 
maintaining a record of information concerning digital 
objects stored on a network. The digital objects are 
stored on the network in a manner that restricts 
unauthorized access to and transactions associated with 
the digital objects, a reference service is provided on 
the network, separate from the storage of the digital 
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objects, for recording information about accesses to and 
transactions associated with the digital objects, 
information about accesses to and transactions associated 
with the digital objects is recorded in the reference 
5 service. Access to the records of the reference service 
is permitted to authorized users. 

Another general aspect of the invention relates 
to managing registration of claims to rights in digital 
objects, copies of the digital objects are stored in a 
io repository in a manner that enables only authorized 

accesses to the digital objects and permits verification 
that the stored digital objects have not been subjected 
to unauthorized alteration. At a registrar which is 
accessible on the network at a different network address 
is from the repository, registration services are provided 
including receipt via the network of registration 
reguests and delivery via the network of registration 
certifications. The objects are accessed at the 
repository via the network for use in providing the 
20 registration services. 

Examples of the invention include the following 
features. Owners of rights in digital objects may 
deposit copies of the digital objects in the repository, 
via the network. There may be multiple repositories, a 
25 set of servers, accessible on the network, are provided 
for the purpose of generating a unigue handle for each 
digital object. The handle for a digital object is 
unigue both across the network and over time. A service, 
accessible on the network, is provided for locating the ' 
30 handle associated with a digital object. The handle is 
used to obtain a pointer to the network location of an 
accessible copy (by "copy- we intend a broader concept 
then the conventional notion of copy; see other sections 
of this application for explanation) of the digital 
35 object. The handle is used to obtain a pointer to the 
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network location of information concerning obtaining 
authorization to use the digital object. The services 
are provided at multiple different locations on the 
network. The handles comprise unique character strings 
s associated with the servers which generated them, a 
handle server, accessible on the network, provides the 
pointer in response to presentation of a handle. 
Multiple servers provide the service, each serving a 
portion of the handle space. Multiple handle generation 

10 servers may generate handles independently. Information 
concerning simple terms and conditions is stored in the 
repository. Information concerning non-simple terms is 
held in a rights management system (it may also contain 
the simple terms and conditions) . Each of the handles is 

15 used to obtain a pointer to a rights management system in 
which information concerning non-simple terms is held. 
Hash values are computed on the handles and the hash 
values are distributed among multiple handle servers, 
each handle server having a table which associates 

20 handles with pointers. 

Another general aspect of the invention features a 
method for providing network based regulation of claims 
in rights in digital objects, and, in connection with 
actions (e.g., registration of rights or obtaining copies 
for consideration) pertaining to regulation of claims in 
rights in the digital objects, using handles to obtain 
authorized access to the digital objects in the 
repository, actions include registration of claims in 
the rights. 

Another general aspect of the invention features a 
network-based method for managing compensation for access 
to digital objects and transfer of rights in digital 
objects, information is stored on the network 
identifying the ownership of rights in digital objects. 
At a rights management system available on the network, 
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requests for rights in digital objects are received. i„ 
response to the requests for rights (e.g., exclusive 
rights), and after successful negotiation of rights 
transfers, requests are issued from the rights management 
s system to the recordation system via the network, to 
record transfers of rights in the digital objects. 

Examples of the invention include the following 
features. The transfer of rights is recorded in the 
recordation system in a manner which is secure against 

10 alteration. The request for transfer of rights typically 
occurs after the owner is compensated using a network 
based method of compensation or other method, or a 
commitment has been obtained to compensate the owner of 
the rights using the network-based compensation method or 

is other method. 

Among the advantages of the invention are the 
following. 

Any kind of digital object may be dealt with, 
owners of digital objects may deposit them in a secure 

20 manner that both restricts access and allows for later 
verification that the deposit has not been altered. 
Detailed records of the history of deposits and of 
transactions related to the objects (e.g., transfers of 
rights) may be kept in a protected location in the 

25 system, while access to those records may be allowed to 
any authorized party on the network. The records may 
include information about the history of revisions and 
derivative versions of objects, and may link objects 
based on other relationships among them. 

30 Thus, in combination the information and reference 

server (e.g., the registrar) and the repositories provide 
a unique capability, applicable to any digital object, to 
provide for protected storage in electronic storage 
facilities and, in a separate facility, secure 

35 maintenance of validation information needed to assure 
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the unaltered nature of the stored object and historical 
information about the object. In this way, it is not 
necessary to store the objects at the same location as 
the validation information and any authorized person on 
s the network (e.g., a court, or a government employee, or 
the rights holder, or a user) may have access to the 
validation and historical information and, if authorized, 
the object itself, when applied broadly to a large 
number and variety of rights holders and users, the 
10 system will produce a digital object infrastructure of 
enormous value to the conduct of business. 

The digital signature, privacy enhanced messaging, 
and other protection mechanisms assure the integrity of 
the system. 

15 The Present manual paper system for mediating 

rights in the use of and dissemination of digital objects 
is replaced by a network-based system that operates 
rapidly, accurately, and efficiently, and will produce a 
freer, higher velocity market in such rights, thus 
20 greatly enhancing the value of the rights. 

Corporations and private institutions may apply 
the invention in a variety of contexts. 

The handles used to uniguely identify digital 
objects are designed to be extensible and expandable to 
accommodate virtually any number of objects over many 
years. The hashing mechanism provides an efficient and 
reliable implementation. 

Other advantages and features will become apparent 
from the following description and from the claims. 

Description 
Figure 1 is a block diagram of a system for 
managing digital objects. 

Figure 2 is a block diagram of an example of a 
system for registration of rights, recordation of 
3S transfers of rights, and rights management. 
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Figure 3 is a block diagram of digital signing and 
verification processes. 

Figure 4 is a block diagram of a public key 
distribution arrangement. 

Figures 5 and 6 are diagrams of handles. 

Figure 7 is a diagram of hash code space. 

Figure 8 is a flow chart of handle processing. 

Figure 9 is a flow chart of a process for appiyino 
for rights registration. 

Figure 10 is a block diagram of portions of the 

system. 

Figures 11 through 13 are flow charts of a 
registration process. 

Figure 14 is a block diagram of portions of the 

system. 

Figures 15 through 17 are flow charts of a process 
of depositing an object in a repository. 

Figure 18 is a block diagram of portions of the 

system. 

Figures 19 through 22 are flow charts of a 
registration application process. 

Figure 23 is a block diagram of portions of the 

system. 

Figure 24 is a flow chart of a process of setting 
up an account. 

Figures 25, 26, and 27 are flow charts of 
processes of retrieving an object. 

Figure 28 is a schematic diagram of repositories 
and naming authorities. 

Figure 29 is a diagram of a composite digital 

object. 

Figure 30 is a diagram of a repository and 
repository access protocol. 

Figure 31 is a diagram of a service request 
program of a repository access protocol. 
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Figure 32 is a diagram of a handle. 

Figure 33 is a diagram of portions of a handle 

system. 

Figure 34 is a diagram of a handle server system, 
s Preliminarily we define several terms and concepts 

which are used in the following discussion (see Figure 
l). 

Formally, a digital object is an instance of an 
abstract data type that has two components, data and 
io key-metadata. The data is typed as described below. The 
key-metadata includes a handle, i.e., an identifier 
globally unique to the digital object; it may also 
include other metadata, to be specified. Possible 
primitive and composite data types for digital object 
is data are discussed below. 

A -repository- 1002 is a digital storage system 
into which digital objects 1004 may be placed and 
retained for possible subsequent retrieval. The 
repository may contain other related information 1006 as 
20 well as management systems 1008. where appropriate, such 
information may be provided to an "information and 
reference server- 1010. The repository has mechanisms 
for adding new digital objects to its collection 
(depositing) and for making them available (accessing) , 
using, at a minimum, a so-called repository access 
protocol. The repository may contain other related 
information, services and management systems. The result 
of retrieving a digital object from a repository may be a 
performance of the digital object (e.g., execution of a 
program) or the digital object itself (e.g., the 
program) . This is important in the case of digital 
objects which are only intended to be performed by users 
(e.g., a video game) rather than making the object itself 
available. A performance of a digital object may be 
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stored as a new digital object and there may be separate 
terms and conditions associated with it. 

Repositories 1102, 1104, 1106 (Figure 28) have 
official, unique names 1108, llio, 1112 , assigned or 
approved to assure uniqueness by a global naming 
authority 1114. m general, the global naming authority 
will assign a name to a local naming authority me, 
1118, 1120. The local naming authority may use this name 
as the name of a repository, m addition, it may extend 
this name to create new names by suffixing the name with 
a ".", followed by a new (relatively) unique name 
component. Each such name represents a naming authority 
and potential associated repository, (i.e., in general, 
repositories will have unique names of the form "X.Y.Z".) 

Note that a repository name is not necessarily the 
name of a particular host. For example, repository 1107 
may correspond to a set of hosts at different physical 
locations. 

A "stored digital object- 1122 is a digital object 
stored in a repository, m addition, handles 1127 are 
expected to be made known to a system 1128 of -handle 
servers", as described below. Such a handle is a 
"registered handle", a "registered digital object" 1124 
is a stored digital object whose handle has been 
registered. (Note that a handle cannot be registered 
until its corresponding digital object is stored) 
Repositories provide users access to stored objects under 
terms and conditions that may be set by the depositor 
and/or a given repository. 

Registered digital objects are entities of 
significance to the infrastructure, since they are stored 
in a repository and made known via the registration of 
their handles. Intermediate entities, such as stored 
digital objects, are defined because they may arise in 
implementations of repositories that provide access to 
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registered digital objects. However, their existence is 
not strictly necessary. For example, a repository may 
offer a service in which it deposits a digital object and 
registers the handle simultaneously, therefore creating a 
5 registered digital object without creating a prior 
stored, but not registered, digital object. (it is 
possible, of course, to create other useful classes of 
digital objects. For example, we may define a proposed 
dlgltal ob l* c * as a digital object whose handle field 
10 contains a string that has not yet been registered and 
whose unigueness may not yet be known.) 

concatenated and composite fljgjjaj afe jecja 

Digital objects are "typed". Thus one can tell in 
a concatenated seguence of digital objects what kind of 
is digital object is present (e.g., the "object itself" or a 
"performance of the object") and where each digital 
object starts and ends. One simple way to accomplish 
this is to include a type field as the first part of the 
seguence of binary digits which contains the necessary 
20 information, it could also be externally maintained 

(e.g., in a properties record 1014 in Figure l, described 
below) . Data types assumed to be in the handles system 
include bit-seguence, digital-object, and handle, and 
also set-of-bit-seguences, set-of-digital-objects and 
25 set-of-handles. other data types can be defined and 
made available to the handles system via the type 
construction operators set-of and compose; these types 
are then registered in a global type registry. 

In contrast, one can create subtypes of digital 
30 objects by introducing new fields of metadata; these may 
be arranged hierarchically. For example, one might 
create a subtype of digital object called 
computer-science-technical-report which has metadata for 
author, institution, series, and so forth. 
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As seen in Figure 29, a digital object may contain 
other digital objects in the sequence of binary digits 
following its handle. A user will be able to identify 
these contained objects from the type fields 1134 of 
those digital objects 1130 contained therein. We shall 
informally refer to digital objects whose data is a set, 
one of whose elements is of type digital-object, as 
"composite digital objects- 1132. a digital object that 
is not composite is said to be elemental. (Note that 
this definition explicitly excludes the application of 
the adjective composite to a digital object whose data is 
another digital object, i.e., whose data is of type 
digital-object, as distinguished from a singleton set of 
this type. Nothing precludes the existence of such 
objects, however. ) 

The terms and conditions of a composite object may 
implicitly or explicitly be unioned with those of its 
constituent objects to arrive at the terms and conditions 
for those constituent objects. Terms and conditions may 
be explicitly imposed only on the composite object, in 
which case they would apply to each constituent object; 
or each constituent may have its own separate terms and 
conditions in addition. (Of course, creating composite 
digital objects may be subject to copyright and any other 
legal restrictions pertaining to its constituent 
objects.) 

Properties record and tr a im»«i-| fln rf rTrr i 

A digital object may have associated with it, in 
the repository or elsewhere, as part of the related 
information 1006, a "properties record" 1014 which is a 
set of database entries that describe properties of the 
digital object. 

A stored digital object also may have associated 
with it, in the repository or elsewhere, an associated 
"transaction record" 1016 which records transactions 
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involving the digital object. The transaction record may 
contain entries such as the time and date of deposit of 
the object 1032, the time and date of each request for 
retrieval of the object, the identity of the requesting 
party 1034, the handle 1012 and service request for the 
object, and the applicable terms and conditions 1036 
including amount and method of payment. Transaction 
records will only be made available to authorized 
parties. Repositories are not required to have 
transaction records persist for any period of time and it 
may store transaction records at various times and places 
as deemed necessary subject to administrative controls. 

The properties record comprises all metadata for a 
digital object, including its key-metadata, but also, 
other metadata the repository may maintain for that 
digital object. Notionally, the key-metadata component 
is a subset of metadata which is invariant for a digital 
object over repositories. Ho restriction is implied on 
how much of the metadata should be included in the 
key-metadata, other than requiring that it include a 
mandatory handle. Possible examples of 
repository-dependent metadata are the general terms and 
conditions for access and usage of the digital object, 
and the date and time of deposit. 

The properties record may contain entries such as 
the identity of a rights management system 1018 (i.e., 
the system that has control over transfers of and 
compensation for rights in that object) , the handle 1012 
for that object, the originator of the object 1020, the 
name of the object (if any) 1022, a description of any 
work or other information or material incorporated in the 
object 1024, the time and date of deposit 1026, format 
information 1028, and stated terms and conditions for 
access and usage of the object 1030. The terms and 
35 conditions in the properties record may allow the user to 
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select which type of action to allow (e.g., retrieve 
object or perforin object) . The user may be allowed to 
negotiate type of action with the RMS. The user also may 
be given no choice of options, in many retrieval cases, 
the user will not know if an option exists. 

The properties record, the transaction record, and 
the digital object all are normally accessible using the 
handle. 



A digital object's data may incorporate 
10 information or material in which copyright, design patent 
or other rights or interests are claimed. There may also 
be rights associated with the digital object itself. An 
author may have submitted a digital object for purposes 
of registering a claim to copyright in a work that may be 
is incorporated in the object, since the copyright pertains 
to the underlying work fixed in the form of the 
particular submitted representation, the rights would 
normally pertain to all representations of the work, 
including, but not limited to, those representations of 
20 the work that are contained in other digital objects. 

The entities discussed thus far give users a 
number of means to include digital objects that contain 
or may be interpreted to manifest the same or similar 
information or material. As an example, a literary work 
25 may be fixed in a number of different formats, e.g. , 

LaTex, PostScript and GIF page images. Bach fixation may 
correspond to a distinct (elemental) digital object, each 
with its own unique handle, and other metadata) . A 
composite digital object may then be created whose data 
30 is the set of these digital objects. Similarly, one could 
create a composite digital object whose constituent 
objects were the fixations of the literary works of 
Shakespeare in PostScript. The handle of this composite 
digital object, in effect, names the PostScript 
35 collection of Shakespeare's literary works. 
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Note that it is possible to construct objects with 
similar effects without using composite digital objects. 
For example, the single digital object intended to 
correspond to a work could have data of type 
set-of -bit-sequences, rather than of type 
set-of-digital-objects, and contain each of the forms of 
fixation therein, in this case, digital objects may not 
exist corresponding to the individual fixations. Another 
possibility is to have a digital object whose data is of 
type set-of -handles, in this case, the handles would 
name the individual fixations (which may not even be 
available from the same repository) . Such a digital 
object may contain other data fields that further 
describe (or annotate) the handles. Yet another 
possibility is to create a markup language which admits 
handles, plus other conventions for expressing how they 
relate to each other (for example, whether the individual 
handles are meant to be interpreted as different 
fixations of the same work, or a list of bibliographic 
citations, etc.) A digital object whose data comprise 
sentences in this markup language could serve to 
represent the same entities as do composite digital 
objects. 

Metft-obi ect : nutabl 1 i fcg 

We use the informal term "meta-object" to refer to 
a digital object whose primary purpose is to provide 
references to other digital objects. Both digital 
objects whose data are of type set-of-handles and digital 
objects in a markup language that admits handles, would 
be instances of meta-objects. 

A digital object may be mutable in that it may be 
changed after it is placed in a repository. Although 
none of the key-metadata may be changed, nor may any 
known digital object that it contains be changed (unless 
the original digital object is also changed) , most other 
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changes are permissible. Minor changes might be made to 
correct a misspelling or other such error; changes to the 
title of a mutable digital object may be permissible. A 
mutable composite digital object could be modified to add 
the representation of an underlying work in a new format. 
Mutability would also be a useful way to allow digital 
objects that are designed to change with time or are 
dynamically computed. 

A digital object that cannot be changed is said to 
be -immutable". If an object is immutable, then, once it 
is placed in a repository, the result of all subsequent 
requests to that repository that are functionally 
dependent on the data of the object must be identical. 
(However, it may be possible to remove an immutable 
object from a repository, or deny access to it at 
different points in time.) That a digital object is 
immutable may be reflected in its key-metadata, it is 
also possible that a given repository may preclude 
changing a stored object by an indication in its 
non-key-metadata. 

Once set, the mutability or immutability of a 
digital object cannot itself be changed. Users who wish 
to achieve a comparable effect would have to create a new 
digital object with similar data and altered metadata. 
The original digital object may then be withdrawn or not, 
as desired. 

Rights management gggfcfia 

The "rights management system" 1038 is a system 
used to negotiate access rights and other rights not 
otherwise specified in the properties record, it retains 
information about transactions, and communicates 
information about approved transactions and associated 
terms and conditions to the repository. Where 
authorized, it also informs the information and reference 
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server about transactions involving rights management for 
recordation purposes. 

The information and reference server 1010 receives 
information from the repository and the rights management 
5 system, it retains a copy of the properties record for 
each digital object, a digital signature or other 
-fingerprint" of the digital object (the digital 
signature and other fingerprint is typically considerably 
smaller than the object itself) suitable for verification 
ib purposes, and a temporal history list of related objects. 
In retains a history of chain of title 1052 to digital 
objects. The information and reference server is 
intended to be used for browsing, verification purposes, 
and to alert users to changes in the system, in some 
is implementations it can be used as a registration and 

recordation server for copyright and other purposes. The 
server may be part of a governmental department, or of a 
private service operation. The information and reference 
server typically would not retain complete digital 
20 objects for storage and retrieval purposes. 

The network would also be accessible to a wide 
variety of rights holders 10 (e.g., authors, owners, 
holders of exclusive rights) . The rights holders may 
have access, when authorized, to the information and 
25 reference server, the repositories and the rights 

management system. The information and reference server, 
the repositories, and the rights management system are 
also potentially accessible by network users 14, who may 
wish to obtain, use, modify, transmit, perform, and 
30 enhance selected digital objects, or the results of 
operations performed by or on digital objects. The 
medium of the network (e.g., the cables, airwaves, public 
switched telephone network) is not shown in the figure; 
but the network medium could be organized as a single 
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local area network, a wide area network, or a broader 

network structure (e.g., the Internet). 

Originator 

An "originator" 1140 is an entity that authorizes 
or validates a set of digital objects; it is responsible 
for each such digital object including making it 
available in the handles system 1142 and defining terms 
and conditions for its use. Every digital object has an 
originator, which may be an individual or an 
organization. Originators may deposit and access the 
digital objects they authorize or validate and may 
authorize others to do so (this also includes the right 
to withdraw or modify the objects) , subject to the 
procedures established by individual repositories. 
Naming authorities have the right to insert handle 
entries for handles they generate into the handle server 
system and to authorize others to do so. An originator 
and/or a naming authority may also delegate this 
authorization ability to others (typically this would be 
to one or more repositories) Such delegation includes at 
least the right to authorize the further deposit of 
digital objects on behalf of the originator and insertion 
of designated groups of handles on behalf of the naming 
authority. Repositories may establish additional 
requirements of various kinds. 
Repository of r«>«ord. 

The initial repository used to deposit a 
registered digital object is designated the "repository 
of record" (ROR) . The ROR is responsible for authorizing 
additional instances of the digital object at other 
repositories, and for making changes or withdrawals of 
such additional instances of the digital objects, usually 
upon the direction of the originator. Once designated, 
the ROR may subsequently be changed by an authorized 
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party to another repository, but the method for achieving 
this is not specified here. 

Each digital object has a -handle", a concise 
unique identifier for a digital object used for storage 
5 and retrieval operations and other repository functions. 
The overall system also includes a handle 
management system 1042 (Figure l; also seem on Figure 2) 
comprising multiple servers which provide handle server 
directory services, handle-to-pointer translation 
10 services (called -handle servers"), and handle generation 
services; payment servers 1044 which provide payment 
authorization services; and a wide variety of other 
possible servers 1046 including those which would provide 
intermediary services between rights holders and users, 
is on one hand, and other servers on the other hand. For 
example a server might provide a service of receiving a 
conventional bibliographic citation to a journal article 
and communicating with an appropriate handle server to 
identify the location of the article on the network. 
20 That service and others could be provided as commercial 
services, it should also be clear that services can be 
provided on a widely distributed basis by multiple 
similar servers at different locations on the network, or 
by single centralized servers. Furthermore, not all of 
25 the digital objects which may exist on the network need 
be covered by the servers of Figure l. Only when rights 
holders choose to subject their objects to the system 
would the services need to be provided. 

There is no requirement that a digital object be 
30 stored in a repository in any particular manner. 

conceptually, the description of a digital object is 
strictly a logical one and is not intended to describe 
any particular implementation. In particular, it is 
possible that, in response to a request to access a 
35 particular digital object, a server runs a program that 
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computes the digital object on the fly. it is possible 
for multiple digital objects to be embedded in a program 
(e.g., a data base manager or knowledge based system) 
that emits them upon request. The program may itself be 
5 a digital object. Thus, accessing and depositing are 
virtual processes, and may or may not involve the actual 
depositing and retrieval of actual objects per se, 
although such actual storage and retrieval is likely to 
be prevalent. 
10 Repository Access Protocol ffl ftp) 

A "simple repository access protocol" (RAP) is 
supported by each repository and discussed below. The 
RAP may be merely a subset of a larger interface protocol 
used by repositories, provided that the functions or 
is operation of the RAP not be affected by any implemented 
supersets of the protocol. In particular, as seen in 
Figure 30, the RAP 113 6 allows for accessing a stored 
digital object or its metadata by specifying its handle, 
a service request type, and additional parameters. If 
this request is complied with, the output of the service 
request is termed a "dissemination" 1138. A 
dissemination is the result of an access service request, 
along with additional data affixed to it. 
Access to a digital object /access no) 

Access to a digital object will generally invoke a 
service program 1150 that performs stated operations on 
the digital object or its metadata depending on the 
parameters supplied with the service request. Defined 
service requests include metadata 1152 , key-metadata 1154 
and digital object 1156; the first requests only the 
metadata, the second only the key-metadata, and the 
latter, the entire digital object (i.e., the key-metadata 
and the data). Other systems-level services 1158 may be 
defined. Possible examples of such additional services 
35 might be encrypt, i.e., return the digital object in some 
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encrypted form, or compress, i.e. store a fewer set of 
bits than supplied with the property that the original 
bits can be regenerated, perhaps exactly. 

In addition, it is possible to have 
5 data-type-dependent service reguests 1157. Possible 
examples of such data-type-dependent services reguests 
might be execute (for digital objects a portion or all of 
whose data component is of type program) , or subpart 
(which reguests only a component of the data or metadata 
10 of the digital object, further specified by some 
parameter) . 

When a digital object is accessed via ACCESS_D0, the 
recipient receives a dissemination, that is, the result 
of the service reguest, along with information such as 
the key-metadata of the digital object, the identity of 
the repository, the service reguest that produced the 
result, the method of communication (if appropriate) and 
a transaction string corresponding to an entry in the 
transaction record. The transaction string is unique to 
the repository, in addition, the dissemination may 
contain an appropriately authenticated version of some 
portion of the properties record for that object, 
including the specific terms and conditions that apply to 
this use of the digital object and the materials 
contained therein. 

As noted above, depending on the nature of the 
ACCESS JX> service reguest, the dissemination may not be 
stored as a digital object per se. it might instead 
include data that is not contained in any registered 
digital object, such as a portion of a digital object's 
data, the digital object data in a compressed format, or 
the result of executing the data of the digital object. 
In all cases, however, the key-metadata (including, of 
course, the handle) of the digital object is included. 
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particular digital object, the digital object say be 
contained in the dissemination, in the sense t J the 

viTl I °? "* "y the ri, ht s associated 

« ob *««- — «»Ple, if th. data of a 

stored digital object repress an episode of a 
television prograe, and th. di.se.in.tion contain, the 
data corresponding only to the first two -mutes of this 
■ television prograe, th. dissection eay be said to 
contain the digital object in a 

n™ _ .. oojeci in a legal sense, even if it 

does not properly contain all of its data. 
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several forms of deposit*) are possible. For 
example, one fore may take data, a handle, and perhaps 
oth.r eet.dat. as argents, and produce a storea ot,L.l 
object and prop«*i., record fro. these arguments. 
Another possible for, may take a digital object as 

d^r;, PerhaP ° ^ • daltlo "«l -tadata, and simply 
deposit it. yet soother fore may take only data and 
certain non-key-metadata, and automatically revest a 

s^ *K rOB k ! " e SerVer ' tten ^itaneously 
store the object and register the handle. 

The DEPOSITS command may be used to replicate an 

o™' di9ital ° bjaet " repositories A " 
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eating eutabl. digital object. Alternatively, , 
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This command provides a uniform and understood wav 
to identify alternate means of accessing a specified " 
repository and/or information about objects in that 
repository. Two possible responses are (i) H o 
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handles; for changing access permissions by individual or 

Two sets of tools are currently provided. The 
first uses electronic mail. The only security is to 

t°\?':t u £ieid in ^ e -* aii header - *** ~— 

uses Mosaic forms. Security is by ID and password, it 
xs intended to use public key encryption. 

The handle system is based on the udp protocol. 

^-^SSTi^ nVWber ° f teanSac "<™ be handled 
10 efficiently, but some security firewalls reject TOP 

IT^JT^T' Ch ° iCe ° f ^ ~ TCP *• Prided 
as alternatives for the local handle server, caching 

server, and client library, but not for the global handle 
15 Purview Of an Rv^ft le SvgJ-ftn , 

whi« h f ° 11W8 ' We Pr ° Vlde e * a »P^ ot operations 

which may be conducted with assistance of the servers and 
services of the kind shown in Figure 1. The operations 
include registration of rights, recordation of transfers 

1 9 ' deP ° Sit ° f ° bjeCt8 in repositories, general 
and use of handles, arranging compensation for use of 
objects and for licensing and transfer of rights fe a 
exclusive rights, in objects (under simple or non-sxmpie 
terms,, use of digital signature and other protective 
ZZT'T t0 in8Ure of the transactions 

t?2 ******* ********** <* eights, and obtaining 
objects from repositories. 

* , * S Seen ^ Fi9Ure 2 ' *» exanple syste » 31 includes 
a digital object management system 32 which includes 
io hardware and software to create and store digital objects 
and manage rights to the objects, m the system, a user 
agent (UA, 34 provides a user interface for interactions 
with other elements of the system. The UA is in the form 

5 to IniTT T" 1 " 9 °" * "**»***<>»' "A may be used 

s to initiate storage of an object within a repository 36 
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In the rights registrar facility 43, the public 
access registration database 4i will provide access to 
information about registered rights and provides a read- 
only interface to a cataloging system 44. The 

s registration system 40 holds digitally submitted rights 
registration applications during application processing. 
The application information is submitted to a tracking 
system 46 for tracking purposes (e.g., for tracking 
examination or status) when the digitally submitted 

o application is received. The recordation system 48 

stores and provides information about transfers of rights 
(and other information pertaining to rights and 
interests. The recordation and registration systems in 
this example form part of a more general information and 
reference service. 

The cataloging system 46 stores information about 
registered rights and provides the basis for public 
(network) access to registration information. 

A registrar workstation 50 allows a registrar user 
to view and print rights registration applications and 
accompanying documents and recordation information and 
accompanying documents. The workstation interacts with 
the registration system to obtain registration 
application information, with the rights management 
systems and repositories to obtain digital objects whose 
rights are being registered, and with the recordation 
system to obtain recordation information and associated 
documents. 

The handle management systems 54 are used to find 
the location of digital objects and the locations of each 
object's associated RMS. A handle for an object may be 
associated with zero or more object pointers, object 
pointers contain location information for locating 
digital objects and/or associated RMSs. Bach object may 
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Public y« Y and BlatoJ Sigmatara T -^ Tr iTny 

There are several security issues that the system 
must solve. The registration systea aust be able to 

s ZTJl ° f ri9htS ^ i8 ^io„ applicant. 

5 This is required since the applicant will charge the 

registration to an account, and it is also required for 

legal reasons. 

When an object is transmitted to either the 
registration system or the repository, the recipient 
io systea must be able to deteraine that the object was not 
altered in any way. when an object is stored on a 
repository, the rights holder of the object aust also be 
able to deteraine that the object was not altered by the 
repository in any way. similarly, when an RMS tells a 
repository to send a copy to an object requester, the 
repository must be able to verify that a valid RMS is 
sending the command to the repository. When any 
correspondence is sent to the rights registration 
applicant from the registration system, the applicant 
»ust be able to deteraine that the registration systea 
was truly the source. As objects and other information 
are transacted between the various system components, 
the privacy of the information aust be ensured. 

The system uses available public key and digital 
signature technology to handle privacy and authentication 
in the system as follows. 

In conventional cryptography, a aatheaatical 
function and a secret key are shared by parties who wish 
to communicate confidentially. Each message to be sent 
is encrypted using the function and key, and the 
recipients decrypt it using the same function and key. 

in conventional cryptography the keys must be kept 
secret and must be distributed by secure means. The 
notions of two Stanford University researchers, Martin 
Hellman and Whitefield Diffie, opened up a new way of 
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thinking .bout key management. One key could be nade 
public (e.g. the on. used for encryption) end the other 
key would be k.pt privet.. anyone knowing the public 

t« lZl T"* ° 0ntWe »"" the person knowing 

the privete key used it to decrypt the .eesage. The 
public key. could be lieted in public directorie. .inc. 
knowing then did not help anyone decrypt 
encrypted using the public key. 
o TOT., researcher, et MOT, Riv.st, sbanir and 

Ad.l„n, later develop* . p. tr of tmctloaB m ^ 
regurrenent. specified ^ Dim . „„ HellMn 

llTtT T kn0 ™ " **• ESi "Sorithne. There ere 
also other known way. to i. P l...nt public key algorithm. 

Smoe either key of e public key cryptogrsphy pair 
can be u«d to perfom the initl.l .ncryption, an 

ITI'T," 9 f*"* M ta aehi ™» the TO cr.t 

k.rof the pair to encrypt ...sages to b. sent. Anyone 
with aces, to the public k.y can decrypt the „ssag. ana 
on domg .o successfully, know, that th. «...,. ^ 
h.v. been sent by th. p«.o„ holding th. corresponding 
secret key. This use of the secret key acts like . 
signeture, .inc. th. d.cryption only works with th. 
etching public key. if the public key for th. sender ls 
stored in a public directory, ,„y recipient can verify 
the identity of the sender. 1 

be used to prove that „ object 102 ha. not n«n eltered 
by anyone after th. object-, rights holder (e.g. „ 
author) ha, fixed th. r.pr...nt«tion of th. object, if 
the author perfom. . h«h 104 ov.r .11 of th. objoct'. 
bits, end then .ncrypts loo th. hash valu. with hi. 
«.cr.t key loo to produce a digit.1 sicm.tur.105, . 
r.ctpi.„t ce„ d.crypt th. hart value, reha.h the original 
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object and compare the two hash values to ensure that the 
object has not been altered. 

one problem that must still be addressed is 
knowing whether a public key 108 found in a directory for 
a given correspondent is valid or a bogus key inserted by 
a malicious person. One way to deal with this is to 
create certificates 110 containing the name 112 of the 
owner of the public key and the public key 108 itself 
This certificate is signed with the private key of a ' 
well-known certificate signing authority 114, shown in 
Figure 6. The public key of the signing authority is 
also published in a certificate which is signed by a 
higher-level signing authority lie. in essence, a 
hierarchy of certificate authorities has been created. 

In order to make an object be private in an 
efficient manner, a combination of public key 
cryptography and conventional private key cryptography is 
used, since public key cryptographic algorithms require 
a substantial amount of computing power, an object will 
initially be encrypted with a secret key algorithm, such 
as DES, which is computationally more efficient. The DES 
private key will then be encrypted with the public key of 
the recipient. This encrypted DES key will be sent to 
the recipient, along with the encrypted object. 

Many of the object and information transfers 
performed in the system are provided by Privacy Enhanced 
Mail (pen, ) which was developed by Trusted Information 
Systems of Glenwood, Maryland. The PEM system (and other 
similar available systems) can provide message privacy 
and correspondent authentication. There are other 
systems other messages will be sent between system 
components via direct connections (e.g., "TCP/IP") . The 
TISPEM library, developed by RSA, is used to provide 
message privacy and correspondent authentication. 
Obiaefc ffflnillfff 
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We turn now to a move detailed discussion of the 
elements of the handle system. 

Handles should be globally unique across the 
network and over time; should be essentially permanent 
since rights on an object may last many years; should not 
have any location information encoded in the identifier's 
namespace, since an object may be located at multiple and 
changing locations over time; the identifier's namespace 
must be variable and unrestricted, since the number of 
digital -objects created may be expected to increase; once 
a user acquires an object's identifier, he should be able 
use the handle to ascertain the current location of the 
object; multiple authorities should be able to generate 
the identifiers. 

In addition, the following constraints on the use 
of an object handle are preferred: users of an object do 
not need to know its location, only its identifier; 
objects may be moved from one storage facility to another 
without affecting users; users should be able to choose 
object providers based upon the terms and conditions 
associated with an object, including its costs. 

The authorization and rules for creating a handle 
are determined on a country-by-country basis, in one 
scheme, as seen in Figure 5, handles are printable 
strings 130, having a country code 132 appended to a 
variable length string defined on a per country basis 
134. 

Within the United States, the variable length 
string could be generated in a form similar to a domain 
name within the Internet, Figure 6. Authority zones 
could be established, and each zone authority could be 
able to assign handles directly or create subzone 140 
authorities. A time stamp 142 and serial number 144 
would be used to create a unique identifier within an 
35 authority zone. 
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con., genera11 *' as — » in Figure 32, a handle 

consists of two logical parts, concatenated with an 
intervening separator character 1202. The two logical 
parts are: 1) name 1204 of a local naming authority, 
■> which controls the handle generation process, and 2) a 
locally unique string 1206, which is assigned by (one of, 
its handle generator(s) . An originator may ask a handle 
generator for a handle, or it may propose a local string 
to be used. The local handle generation process should 
insure that local strings are unique. Handles have no 
prescribed maximum length in principle, but there will be 
a default length in existence at any time which can be 
adjusted upwards if necessary. 

For handles to be unique, the names of local 
naming authorities are controlled by the global naming 
authority 1114 (Fig. 28) for the handle system. The 
global naming authority generates names for local naming 
authorities, and assigns these to local naming 
authorities for use by the handle generators they 
authorize. A prospective local naming authority may 
propose a name for itself to the global naming authority 
for validation and registration. A local naming 
authority, named, say, « X ", may create additional 
derived naming authorities of the name -X.Y-, etc., each 
authorizing its own handle generator. 

in addition to the first globally assigned 
component (e.g. «x«) , each subsequent component field of 
a naming authority name (e.g. -¥«, or »z«») must be 
non-null and not contain the character There may be 

other restrictions on the non-alphanumeric characters to 
be used in naming authority names, m particular, the 
default separator character is (so, e.g., 
"X.Y/local-string - is a typical handle from'the naming 
authority "X.Y"). other separator characters, and a 
syntax for defining another separator characters, (from a 
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restricted class of non-alphanumeric characters) may be 
defined, and may entail other restrictions on the 
possible characters used in naming authority names, e.g., 
a conceivable syntax is to specify a non-default 
s separator by an initial non-alphanumeric character, so 
that "%X.Y%local-string" is a valid handle. Otherwise 
identical handles with different separators may be 
identical or distinct, escape characters for restricted 
characters may exist, and the separator characters may be 

IP restricted (e.g. , -whether «a/b" is a possible naming 
authority name that can only be used with a non-default 
separator) . initially, naming authority names could be 
issued conservatively, being restricted to alphanumeric 
characters. An indirect handle is a special type of data 

is field that can be held in a handle record. The data 
field contains the address of a handle server, with a 
specific data type to indicate that this is an indirect 
handle. A handle server addresses is either an IP 
address or a domain name. One use of an indirect handle 

20 . is to allow reorganization of handles amongst handle 
servers. Indirect handles are left as forwarding 
addresses. 
Naming aathgrlfcjfig 

The name of a naming authority, n, consists of one 

25 or more strings, separated by periods. Examples are: 

berkeley.cs 

enri . cs-tr . technology 

The high-order part of the name ("berkeley" in the 
first example) is issued by the global naming authority. 
30 Example. The global naming authority issues the 

name "enri". Future naming authorities, created by enri, 
might be "cnri.es- tr" or "cnri.xiwt". 
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As seen in Figure 33, each naming authority, n, 
has at least one super-administrator 1210 who has full 
privileges for that naming authority 1212, including 
permission to create a lower order naming authority, 
s n.n', with its own super-administrator. This 
super-administrator creates permissions for 
administration of handles within that naming authority 
1214, and can also create new naming authorities, 
n.n'.n", and so on. Super-administrators can delegate 
-10 privileges to other administrators, including the 
privilege of creating naming authorities. 

Example. The super-administrator for w cnri.cs-tr" 
can create a naming authority M cnri.cs-tr. technology". 

Every naming authority has associated with it a 
15 primary handle server, denoted by P. when a new naming 
authority is created, the primary handle server is 
initially set to be the global handle server, G. 
Thereafter the administrator of the naming authority can 
designate any handle server as its primary handle server, 
20 p. 

Whenever the naming authority, n, creates a 
handle, n/d, either the handle, n/d, is stored in P or an 
indirect handle is stored in P, indicating that n/d 
exists and pointing to a handle server that holds n/d. 

25 Thus the primary handle server of any naming authority 
has handle records for all naming authorities that the 
naming authority has created. 

When a new naming authority, n.n', is created, it 
is given a handle. The form of the handle is: n.n'. The 

30 data part is null. The data field of the handle record 
contains the address of the primary handle server, P. 

The handle for the naming authority is stored both 
in the global handle server 1216 and in the primary 
handle server of n. Thus the global handle server has 

3S records for all naming authorities. 
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Handle generators 

The handle generator 1220 nay be a person, an 
organization, or a fully-automated process running on 
some machine or a set of machines. An originator may 
5 control a naming authority, but there may be naming 
authorities that are not controlled by originators. 

An originator may propose handles to be assigned 
to its digital objects. The handle generator need not 
assume any responsibility for insuring that a handle 
10 which it generates is associated with any particular 
digital object; that correspondence may be left to the 
originator. 

Handle generators create new handles on demand of 
object rights holders who wish to have handles assigned 

15 to objects. 

When an object is deposited in a repository, the 
repository contains a copy of the object plus 
identification of certain simple terms and conditions for 
a obtaining a copy of the object and using it. The 

20 rights management system contains non-simple (i.e., 
requiring additional negotiation) terms and conditions 
for obtaining a digital object and using it, and could 
also contain simple terms. The pointer to the repository 
may be null if the object is not available on-line. 

25 Certain objects may be required to be persistent for 
legal and other reasons. The pointer to the rights 
management system may be null if only simple terms and 
conditions contained in the repository {or null terms and 
conditions) govern the use of the object. 

30 Handle Servers 

Handle servers have the following characteristics: 
a handle server holds pointers associated with a subset 
of all handles; handles are assigned to handle servers 
based upon hash values computed on the handles; handle 
35 servers are assigned ranges of hash values; the set of 
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all hash values is partitioned among the set of all 
handle servers. This leads to a highly efficient and 
reliable mechanism for locating objects and from handles. 
Other less efficient or less reliable methods could also 
5 be used. Handle servers may be configured to broadcast 
requests for handles to other handles servers , further 
enhancing the reliability and effectiveness of the 
system. 

As seen in Fig. 34, the handle server system 1230 
io includes handle servers 1232 and handle directory servers 
1234 located at certain well known locations. The 
directory servers will maintain a table of network 
addresses of handle servers (generally, each handle 
server will contain such a directory) . This table will 
15 generally be downloaded by each participating site 

frequently enough to be "acceptably" up-to-date at all 
times. 

Global Handle Server 

The global handle server is a distributed system 
20 that stores and resolves handles. It is publicly 

accessible. The system is highly secure, is fault 

tolerant, and designed to run continuously. The global 

handle server is denoted by G. 

One function of G is to store handle records 1236 
25 for items that must be retained over very long periods of 

time, such as copyright registration, or legal records. 

G also stores handles for all naming authorities and 

local handle servers. 

G is a public service and any client can ask G to 
30 resolve any handle. Since the handles for all naming 

authorities and registered handle servers are stored in 

G, and G is public, the name of every naming authority, 

n, and its primary handle server, P, are public and 

available to all clients. 
35 Local Handle Server 
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Local handle servers are a local option. They 
work in conjunction with the global handle server to 
store and resolve handles locally. They provide 
increased local control of handles, distribute the 
5 computing load between central and locally supplied 
equipment, and provide simple access controls to handle 
data. By storing individual handles on both a local and 
the global handle server, they can be used to back up 
each other. 

10 Local handle servers can be created and operated 

by naming authorities or repositories. Other 
organizations, such as service bureaus, can also create 
and run local handle servers. For a local handle server 
to become a registered part of the overall handle system, 

15 it must be given a handle (by some naming authority) . 
This handle is then stored in G, the global handle 
server. 

Local handle servers are not public services. 
Permissions for a client to use local handle server to 

20 resolve a handle are set by the system administrators. 
Currently, the only such method of access control is by 
the IP address of the client that makes a query to the 
handle server. 

Each local handle server is implemented as a set 

25 of one or more server computers. When several computers 
are used, handles are distributed amongst them using a 
hash table. For reasons of performance and reliability, 
data may be replicated across these computers, but this 
is hidden from client programs. 

30 Caching handle servers 1242 also may be run at 

local workstations on behalf of individual users to store 
location information for frequently used handles. 
Storing Handles 

Naming authorities can choose to store the handles 
35 that they create on any handle servers for which they 
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have access permissions, local or global. When a handle 
is stored in several servers, one is declared to be 
authoritative* This can be the global handle server, G, 
the primary handle server, P, or another local handle 
5 server, subject to the naming authority having 

administrative permission to store handles on that handle 
server. 

G is publicly accessible for handle resolution. 
If a handle is stored in G, then any client can resolve 

10 it. Handles stored on other handles servers can be 

resolved only by clients that have suitable permissions. 

Example. The naming authority "cmu.cs. robot ics w 
might choose G as authoritative for the handle to an 
important object, and also enter the handle in its 

15 primary handle server, P, for local use. 

When n creates a handle, it makes a record in P, 
the primary handle server of naming authority n, with an 
indirect handle to each handle server that is able to 
resolve this handle. This indirect handle indicates that 

20 the handle exists and can be resolved by a query to the 
appropriate handle server. Access controls on P should 
be set so that any client with permission to query the 
handle server is able to read this indirect handle. 
Example. The naming authority 

25 "cnri.cs-tr. techno logy" creates a handle 

•♦cnri. cs-tr. technology /dl w which is stored in the global 
handle server. An indirect handle is stored in the 
primary handle server indicating that a handle "cnri.cs- 
tr. technology /dl" is stored in the global handle server. 

30 Resolution of Handles 

The handle system provides a client library of 
routines 1244, currently written in the C programming 
language. They interface with the global and local 
handle servers and with caching servers. They can be 
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included In client programs that wish to contact handle 
servers • 

Caches are used by clients to reduce the load on 
the other handle servers, particularly the global handle 
5 server, G. Resolution of handles using caches is, in 
general, faster than resolution without caches. The 
caching server is a shared cache to be used by a group of 
clients. The architecture also allows a cache to be 
incorporated within an indivi dua l client. 

10 The recommended configuration is for any client, 

C, to have an assigned cache, CI. This can be integrated 
into the client or can be caching server shared by 
several clients. CI, itself, may be connected to a higher 
order caching server, C2. To avoid resolution involving 

15 many steps, the recommended configuration is to have no 
more than two levels of caches, CI and C2. 

A proxy server 1246 has been developed that acts 
as a client to the handle system for use with World Wide 
Web browsers and other clients. The client passes a 

20 handle to the proxy server which attempts to resolve it. 
If the handle can be resolved into one or more URLs, a 
URL is returned to the client. 

The proxy server is configured as a separate 
server to be used by a group of clients. The recommended 

25 configuration is that every organization that wishes to 
use the handle system should provide both a caching and 
proxy server for its community. 

A proxy server has been developed in consultation 
with the National Center for Supercomputing Applications, 

30 the developer of Mosaic, but is intended to work with 
other clients that support proxies. Mosaic will be 
configured to use the proxy when a handle is specified in 
place of a URL. The proxy server will be supported by 
future releases of Mosaic. It is also compatible with 

35 the earlier proxy server developed by CERN. 
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We now describe how a client, C, resolves any 
handle, h. Note that (a) each handle server can be 
implemented as one or more server computers; (b) checks 
are required to prevent looping through indirect handles; 
5 (c) the client may not have access permissions for all 
local handle servers; (d) the client request may ask for 
all the data in a handle record or data of specified 
types only; (e) because the local handle servers are 
independently managed, the client may encounter 
10 inconsistent data or unacceptably poor response from a 
server. 

If the client, c, is not attached to any caching 
server, it uses the following steps to resolve a handle r 
h. 

15 1. c sends a query to G. 

If the handle record for h is stored in G, 6 
resolves h. 

Otherwise, G returns the address of P, the primary 
handle server of naming authority, n. 
20 2. If h is not yet resolved, C sends h to P. 

If h is stored in P and C has the correct access 
permissions, P resolves h. 

Otherwise, if there is an indirect handle to 
another handle server, M, which stores h, P sends the 
25 client the address of M. 

3. If h is not yet resolved, the client, C, sends 

h to M. 

If the client has the correct access permissions, 
M resolves h. (If C does not have permission, it should 
30 try other handle servers that hold the handle*) 

If the client, c, is connected to a cache, Cl, 
resolution of h follows these steps: 

1. The client, c, asks Cl to resolve h. 
If the handle record of h is in the cache, the 
35 handle record is returned to c. 
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2. Otherwise , if the identity of P, the primary 
handle server of naming authority n, is stored in Cl, CI 
resolves the handle following steps 2 and 3 above in the 
description of resolution without caching* 
5 3. If the handle has not been resolved, and Cl is 

connected to a higher cache, C2, Cl asks C2 to resolve 
both h and P, and pass the results to Cl to be saved in 
Cl's cache. 

If h and P are not in C2's cache, the request is 

10 passed to the next higher cache, until the handle is 
resolved until the highest cache is reached. (The 
recommended configuration is to have no more than two 
levels of cache.) 

4. If there is no higher cache, then the cache 

15 sends a request to G asking for the resolution of h and 
P. The resolution algorithm then continues as in the 
description of resolution without caching. 

The handle server system is intended to be a means 
of universal basic access to registered digital objects. 

20 in the worst case, a user can present: a handle to a 

handle server and be advised of some repository which an 
authorized party has asserted contains the digital object 
designated by the handle. The handle server is not meant 
to be the only, or even primary, means, to locate 

25 repositories. Primary access may be provided locally and 
also by value-added service providers, likely in a 
variety of different and possibly incompatible ways. 
Users interacting with such services may not encounter 
handles; and such services may interact with repositories 

30 via RAP or via protocols that do not involve handles. 

Handle servers provide a number of services, three 
of which are RESOLVE, INSERT, and DELETE, A party that 
is authorized to insert, delete and otherwise change 
handle entries for a particular naming authority is 

35 called a handle administrator. A naming authority will 
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generally designate one or more repositories to act as 
handle administrators on its behalf. This designation 
will be made known by the naming authority to the handle 
server system, 
s RESOLVE 

A handle is sent to a handle server to locate 
network addresses of repositories containing that object. 
The handle is first mapped to locate the handle server 
from the handle directory server table but is not 

10 otherwise interpreted. One can also supply a handle to a 
separate system, which invokes the above procedures to 
find the stated object. Local handle servers may use any 
technique to do the mapping. The handle servers 
maintained as part of the infrastructure map the handles 

15 by hashing them. 

To resolve a handle, a handle server receives as 
input a handle and returns some or all of the fields of 
typed data in the corresponding handle record. The 
client can request that all data fields in the handle 

20 record be returned or only those fields that contain data 
of a given type. 

No guarantee is made that the identified 
repositories will provide the designated object. Rather, 
the user is assured only that the specified repositories 

25 are where authorized maintainers of repository services 
have indicated particular digital objects reside. 

Since a handle is just a unique string, it can be 
mapped to an actual repository by any of several 
mechanisms, including a mechanism that attempts to 

30 interpret the string. Repository names are not actual 
network addresses; they must first be mapped to network 
locations. The method for accomplishing these mappings 
is not specified. The handle service is one available 
means for both kinds of mappings; it would specify at 

35 least the location of the interface that supports the rap 
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protocol for a given repository. There may also be a 
need to explicitly provide a country identifier for 
repositories, naming authorities and/ or originators. For 
the present, however, country identifiers are be omitted. 
5 When a repository is identified by a handle 

server, it will be most efficient to map the handle 
directly into the network address (or addresses) of the 
repository. This mapping avoids having to do a double 
lookup fr om reposito ry name to repository location. 

10 However, if the location of the repository were to 

change, the handle server would have to be notified so it 
could make the corresponding changes. It is possible 
that certain repository names may resolve to broadcast 
addresses to locate specific machines. This might be the 

15 case where a single repository consists of multiple 
machines on a local area network at a given site. The 
handle administrator may determine whether to store IP 
addresses or domain names or other information in the 
handle server. The entries are typed and therefore one 

20 or more of the above information types may be provided by 
the administrator for retention in the handle server. 
INSERT (DELETE) 

Information associating handles with network 
services are inserted into (deleted from) the handle 

25 server system by the handle administrator or other 
parties authorized by it. Such authorized parties 
include repositories of record. The repository of record 
is presumed to make known to the handle server system 
that it contains (or no longer contains) a particular 

30 digital object some reasonable time after the digital 
object is deposited in (withdrawn from) it. Similarly, 
the repository of record would make known to the handle 
server system the identity of other repositories which it 
authorizes to store a given digital object. The handle 

35 server system may perform certain administrative 
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functions upon receipt of unauthorized requests. In 
addition, some form of reporting may be desirable to 
insure that entities that misbehave can be detected. 

The handle server system is intended as a safety 
s net of information about where digital objects reside. 
There will no doubt be other, valuable services that 
provide information to users about the location of 
digital objects in repositories. 

We dp not require repositories to_provide_ a 

10 description of their contents. Repositories may not 
house coherent collections, and hence, querying or 
searching a repository may be a service appropriate only 
to the repository administrator, not to a user. 
Presumably, such capabilities will exist in the form of 

is value-added services. It is such services, rather than 
repositories per se, that users would interrogate to 
identify digital objects of a certain nature. Such 
services may, of course, be offered by repositories 
themselves, especially in the case when one is intended 

20 to house a coherent collection. However, such a server 
is not a requirement of a well-behaved repository. 

In one example, the handle server directory 59 
holds a table 149 which associates hash ranges 150 with 
domain names of handle servers 58 (Figure 7). 

25 Obtaining Pointers from a Handle 

Given a handle, the following steps, shown in 
Figure 8, are followed to obtain a set of pointers 
associated with the handle. 

In a first step 170, a client system downloads the 

30 table that associates hash ranges with handle server 

domain names from the handle server directory for future 
use. The client also can omit this step if it has 
previously stored the table; frequent changes in the 
table may necessitate doing this every time. In a later 

35 step 172, assume the system obtains a handle for which 
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pointers are desired. The system then generates the hash 
code for the handle using a predetermined hashing 
algorithm (step 174) and consults the hash range/handle- 
server-domain-name table to determine the domain name of 
s the appropriate handle server (step 176). The system 
subsequently sends the handle to the handle server as 
part of a request pointer information UDP packet (step 
178) . 

The^ ha ndle serve r then returns its response to the 

10 requesting system. If the handle server found the 
pointers, a list of pointers is returned (step 180). 
This could include pointers to use one or more 
repositories and one or more RMS's. If the handle was 
sent to the wrong handle server, it returns a not- 

15 responsible-for-handle message (step 182}. In this case, 
the client system should download the hash range/handle- 
server-domain-name table from the handle server directory 
again and attempt the mapping again. The requester will 
determine how many times to try before giving up (and 

20 this same approach is used in other similar situations 
described below) * 

If the request was sent to the correct handle 
server, but the requested handle could not be found, the 
handle server returns a handle-not-found message (step 

25 184). 

Overview of Application for Rights Registration 

There are two mechanisms used to register rights: 
an applicant may apply for a rights registration on an 
object which is located on his own system 42 or on an 
30 object which has been stored in a repository 36. 

In order to submit and process a rights 
registration application the following general steps 
(described in more detail later) must occur. 

First, as seen in Figure 9, the rights 
35 registration application is created, and the application 
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and the associated object are submitted to the 
registration system. The steps required to perform this 
depend on the location of the digital object. In 
registering an object which is located on the applicant's 
5 own system, the applicant first makes the object 

available to his own system (if it was created somewhere 
else) (step 60) . The applicant then runs a rights 
registration program in a step 62, and he fills in a 

r ights registrat .ion application template . - The 

10 application and the associated object are electronically 
mailed (as a PEM message) to the registration system 
(step 64), which performs simple syntactic checking on 
the application (step 66), and verifies that the 
associated object has not been corrupted (step 68) . 

15 If the object has not yet been placed in the 

repository, the applicant first places the object in the 
repository (step 70). The applicant then runs the rights 
registration program, and he fills in the copyright 
registration application template (step 62). The 

20 application and the object's handle are electronically 
mailed (PEM) to the registration system (step 64), which 
performs simple syntactic checking on the application 
(step 66) . The registration system then retrieves the 
object from the repository in a step 72 and verifies that 

25 the retrieved associated object has not been corrupted 
(step 68) • 

After the registration system has checked the 
object, it creates an initial Receipt in Progress (RIP) 
record and sends it to the tracking system (step 74) . 
30 The tracking system verifies that the account number 
presented in the record is valid and that sufficient 
funds exist in the account to process the application 
(step 76) . 

The application and the associated object can now 
35 be accessed by the rights examiner, by running an 
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examiner 's user interface program on the examiner's 
workstation (step 78). Once the examiner approves the 
application, the registration system assigns a 
registration number, and the system creates the rights 
registration certificate (step 80) . A copy of the 
certificate is mailed electronically to the rights 
registrant. An updated RIP record which shows the 
registration application's final status is subsequently 
sent to the tracking system (step 82). 
Registering an Obiectnot In a Repository 

The detailed steps for registering without first 
depositing a copy in a repository are shown in Figures 10 
through 13. 

First, the user 42 (the rights applicant) 
generates a digital signature for the object (step 250) 
using a private key and makes the object 43 (in one 
file), digital signature 45 (in a second file), and 
public key certificate chain 47 (in a third file) 
available to the UA system 34 (step 252) . The UA user 
supplies rights registration application information 49 
by filling out a form on the screen. If the user does 
not fill in the publication date field, then the object 
is considered unpublished by the rights registrar. If 
the field is filled in, then the object is treated like a 
published work. The UA user digitally signs the rights 
application information in a step 254. 

The UA then sends a pem/mime message 202 to the 
registration system 40. (MIME is a multimedia electronic 
mail specification to allow for multimedia objects to be 
handled.) The message contains the object, the user's 
digital signature 45 over the object, the public key 
certificate chain 47 for the user, the rights 
registration application 49 information, a digital 
signature (not shown) over the rights registration 
application information, and the UA user's public key 
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certificate chain (not shown) (step 256) . The entire 
message is signed by the UA user. 

The registration system 40 receives the PEM/MIKE 
message. An entry recording the receipt of the message 
5 is placed into a log file in a step 258. 

The registration system verifies that it accepts 
rights applications from the distinguished name of the UA 
user (step 260) . If not, it returns a message to the OA 

user, and the verification failure is recorded in the_log 

10 file (step 262) . 

The registration system attempts to validate the 
digital signature over the entire message in step 264. 
If validation fails (i.e., the decrypted hash value does 
not match the computed message hash or one of the 

as certificates in the public key certificate chain has been 
revoked) , a message is returned to the UA user. The 
validation failure is recorded in the log file (step 
262) . If the validation succeeds, then an application 
received message is sent to the UA user (step 266) . 

20 The registration system attempts to validate the 

rights registration information (only simple checks are 
performed) in step 268. if validation fails, a message 
is returned to the UA user. The validation failure is 
recorded in the log file (step 262) . 

25 if the object was included in the pem/MIME message 

(step 270) , the registration system attempts to validate 
the digital signature over the object (step 272) . If 
validation fails, a message is returned to the UA user. 
The validation failure is recorded in the log file (step 

30 262) . 

If the validations of the application information 
and the object (if it was included in the PEM/MIME 
message) were successful, then the following are entered 
in step 274 into the registration system's work in 
35 progress database: the application information; the 
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digital signatures; the public key certificate chains; 
and the object (if available) . The entry into the work 
in progress database is recorded in the log file. 

If the PEM/MIME message did not include the object 
5 (step 276) , the registration system attempts to retrieve 
a copy of it in step 278. If the attempt fails, a 
message is sent to the UA user (step 280) . The 
application information, digital signatures, and public 
key certificates are removed from the work in progress 

io database. Entries are made in the log file recording the 
retrieval failure and the removal of the information from 
the work in progress database in step 282. 

If the retrieval attempt succeeds, then the 
registration system attempts to validate the digital 

15 signature over the object in step 284. If validation 
fails, a message is sent to the UA user (step 280). The 
application information, digital signatures, and public 
key certificates are removed from the work in progress 
database. Entries are made in the log file recording the 

20 validation failure and the removals from the work in 
progress database (step 282). 

If the object has been published (the rights user 
filled in the published date field) (step 286), then the 
object is placed in the acquisition queue in step 288. 

25 The registration system now prepares an initial 

Receipt In Progress (RIP) record (step 290) . The 
registration system converts the information located in 
the title and claimant name fields in the registration 
request into the title and claimant name fields in the 

30 RIP record. The following conversions are performed: 
title words that are located in a stop word list are 
deleted and title words that are located in an 
abbreviated terms list are abbreviated. 

A bar-code number (or other identifier) is 

35 assigned to the registration request (step 290) . A 
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verify and debit request, which contains the bar-code 
number (and other RIP record information) is formatted 
and sent to the tracking system via the Pile Transfer 
Protocol (PTP) in step 292. 
5 The tracking system verifies the account (step 

294) and debits the requested amount from the account. 
If the account is not valid, the tracking system will 
send an invalid account number presented message to the 
re gistration system (step 296) . If the account is valid, 

10 but insufficient funds exist for this transaction (step 
298) , then the tracking system will send an insufficient 
funds message to the registration system (step 296) . in 
either error case, the validation failure is recorded in 
the registration system's log file; and the rights 

15 registration application is removed from the works in 
progress database (step 282). If the object was 
unpublished, it is deleted from the registration system 
in step 300. If a published object and registration 
request is resubmitted, it is possible that a object 

20 might be placed in the acquisition queue multiple times. 
Manual procedures catch the duplicate entries. 

If the tracking system 46 (Figure 10) successfully 
performed the account verification and debit processing, 
it sends an account is OK message to the registration 

25 system in step 302. the tracking system prepares an 
initial RIP record and places it in it' s database, if 
the object was unpublished, a copy of it is placed into 
the acquisition queue. 

The registration system moves the registration 

30 request to the examiner queue database in step 304. The 
registrar user's workstation 50 (Figure 10) now has 
access to the registration request. The examiner uses 
workstation 50 to view the object on the screen, to add 
his name to the examined by line on the application form 

35 and to record the class designation for the rights 
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registration (step 306). The converted form of the 
author and title (as stored in the RIP record) are also 
shown to the examiner. 

If the examiner approves the application (step 
5 308), an examination-is-approved message is sent from the 
workstation to the registration system in a step 310. 
The registration system assigns a registration number 
(step 312) , and the system creates and digitally signs 
the rights registration certificate, which includes the 

16 registration number" and - the date on which registration 
was granted (step 314). The rights registration 
certificate is sent in a PEN message to the UA user in a 
step 314. The certificate may be sent directly to the UA 
or indirectly via the repository. The certificate is 

is archived on the registration system (step 312). The 

certificate also could be stored on a system that retains 
the scanned images of the manually created certificates. 

If the examination results in the rights 
registration application being rejected, the examiner 

20 uses the workstation to send a rights registration 
rejection PEM message via the UA to the applicant 
explaining the rejection (step 318) . 

If the registration was approved or denied, an 
updated RIP record is forwarded to the tracking system in 

25 a step 320. Once the tracking system has added the 

record to its database, it sends a RIP-record-update-OK 
message to the registration system (step 322). 

In step 324, the registration system moves the 
registration request to the cataloging system. The 

30 cataloger's workstation 57 (Figure 10) now has access to 
this registration request. 

Using a connection to the cataloging system, the 
cataloger creates the cataloging information in step 326. 
When the task is finished, the workstation sends a 

35 finished catalog message to the registration system (step 
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328). The registration system places a registration- 
application-processing-complete message in the log file 
(step 330) . 

Placing an Object into a BSBaaitgrv, 
s Alternatively, the rights holder may choose first 

to place an object into a repository, as shown in Figures 
14 through 17. 

In a first step 350, the user 42 makes the object 
(object) available to the UA 34. The UA then sends a 
10- request "for - ahahdie to a handle generator system 36 
(step 352). 

The handle generator system sends a handle to the 
UA system (udp) in step 354. 

The UA sends a PEM message to the rights manage- 
15 ment system 38 containing the handle, any non-simple 
terms and conditions for obtaining a copy of the object 
(which must include free access to the object for the 
registrar), and the list of distinguished names of those 
who are allowed to make changes to the information 
20 (stored in the RMS) which is associated with the handle 
(step 356) . The PEM message is signed by the UA user. 

The RMS verifies that it accepts new submissions 
from the distinguished name of the UA user in step 358. 
If not, the RMS sends an invalid-distinguished-name PEM 
25 message to the UA user and discards the contents of the 
received message (step 360) . 

The RMS validates the digital signature on the 
received PEM message (step 362) . If the validation 
fails, the RMS sends an invalid-digital-signature PEM to 
30 the UA user and discards the contents of the received 
message (step 360) . 

The RMS verifies that it does not already have a 
set of terms and conditions stored for the handle (step 
364) . if it does, it sends a terms-and-conditions- 



WO 97/43717 



PCTYUS97/07834 



- 55 - . 

already-registered PEM to the UA user and discards the 
contents of the received message (step 360) . 

The RMS stores the handle and the associated terns 
and conditions (step 366) and sends a confirming PEM to 
s the UA user (step 368) . 

In a step 370, the UA system computes the digital 
signature over: the object's handle; a date/time group 
(the nominal date/time of submission of the object to the 
repository); and the object. 

ior "The UA^system sends a PEM/MIME message to the 

repository 36 (Figure 14) containing the object's handle, 
the submission date/time group, the object (or the 
information needed to retrieve a copy of the object) , the 
UA user's digital signature over the above, the UA user's 

15 public key certificate chain, the simple terms and 

conditions for the object, if any, and the distinguished 
name or names of the RMS(s) holding the non-simple terms 
and conditions for the object, if applicable. The entire 
message is signed by the UA user (step 372) . 

20 The repository verifies that it accepts object 

submissions from the distinguished name of the UA user in 
a step 374. If not, it sends an invalid-distinguished- 
name PEM message to the UA user and discards the received 
message (step 376) . 

25 The repository validates the digital signature 

over the entire message in step 378. If the validation 
fails, the repository sends an invalid-digital-signature 
PEM message to the UA user and discards the received 
message (step 376). 

30 If the object was not included in the received 

PEM/MIME message (step 380) , the repository attempts to 
retrieve a copy of the object (e.g., via anonymous FTP) 
in a step 382. If retrieval fails, the repository sends 
an object-retrieval-failed PEM message to the UA user and 

35 discards the received message (step 376) . 
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The repository validates the OA user's digital 
signature over the handle, nominal submission date/time 
group, the object (step 384), and the reasonableness of 
the submission date/time group (not in the future, not 
5 too far in the past) (step 386) . If either of these 
validations fail, the repository sends an invalid- 
submission PEM to the UA user and discards the received 
message (step 376) . 

In step 388, the re posi tory st ores the object's 

io handle, the submission date/time group, the object, the 
UA user's digital signature over the above, the UA user's 
public key certificate chain, the simple terms and 
conditions for the object, if any, the distinguished name 
of RMS, if applicable, and other properties. The 

15 repository then computes its own digital signature over 
the handle, the submission date/ time group from the 
received message and the object (step 390). In step 392, 
the repository sends a PEM to the UA user containing the 
handle, the repository's digital signature, and the 

20 repository's public key certificate chain. 

In step 394, the UA system verifies the 
repository's digital signature over the handle, date/ time 
group, and object. The UA system then stores the handle, 
the nominal submission date/ time group, the object, the 

2S repository's digital signature, and the repository's 
public key certificate chain (step 396) . 

The UA system computes the hash of the object's 
handle using the handle system hashing function (step 
398) . The UA system then looks up the domain name of the 

30 handle server 38 responsible for the handle in its cached 
copy of the hash value/handle server table (step 400) < 

In step 402, the UA system sends a PEM to the 
handle server containing the handle, and one or more 
pairs of domain name of repository and domain name of the 

35 RMS, and a list of distinguished names of persons who are 
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permitted to change the pairs of domain names associated 
with the handle. The message is signed by the UA user. 

The handle server receives the PEM message and 
verifies that it is responsible for the handle in step 
5 404. If not, it sends an invalid-handle-server-selected 
PEM to the UA user and discards the other information 
(step 406) . If the UA system receives an invalid-handle- 
server-selected rejection message from the handle server, 
it downloads a new copy of the hash value/handle server 

io ~table~frOTi the handle Server directory 59 (Figure 15) 
(step 408) and repeats steps 398 through 404. 

If the handle server is responsible for the handle 
submitted by the UA system, it validates the digital 
signature over the PEM message in step 410. If the 

15 validation fails, the handle server sends an invalid- 
digital-signature PEM message to the UA user and discards 
the other information (step 412). 

The handle server verifies that it accepts 
submissions from the distinguished name of the UA user in 

20 step 414. If not, the handle server sends an invalid- 
distinguished-name PEM message to the UA user and 
discards the other information (step 412). 

The handle server verifies the syntax of the pairs 
of domain names submitted with the handle in step 416. 

25 If it detects any errors, it sends an invalid-handle- 
submission-record syntax PEM message to the UA user and 
discards the other information (step 412). 

The handle server stores the handle, the pairs of 
domain names, and the list of distinguished names (step 

30 418) and sends a PEM acceptance message to the UA user 
(step 420) . 

Register ing an Object Already in a Repository 

After the object has been deposited, an 
application to register may be submitted (Figures 18 
35 through 22) . 
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The user (the rights applicant) 42 first generates 
a digital signature for the object (step 450) and makes 
the digital signature (in a file) , and public key 
certificate chain (in a second file) available to the UA 
system 34 (step 452). 

The UA user supplies the rights registration 
application information by filling out a form on the 
screen in step 454. This includes the handle 203 for the 
obj ect already stored in a repository. Any object stored 
in a repository is considered published by the rights 
registrar. Therefore, the publication date field must be 
entered in the application form. The UA user digitally 
signs the rights application information. 

In step 456, the UA system sends a PEM/MIME 
message to the registration system 40 containing the 
object's handle, the user's digital signature over the 
object, the public key certificate chain for the user, 
the rights registration application information, the 
digital signature over the rights registration 
application information, and the UA user's public key 
certificate chain. The entire message is signed by the 
UA user. 

The registration system receives the PEM message. 
An entry recording the receipt of the message is placed 
into a log file in step 458. The registration system 
then verifies that it accepts rights applications from 
the distinguished name of the UA user (step 460) . if 
not, it returns an unknown-account PEM to the UA user, 
and the verification failure is recorded in the log file 
(step 462). 

The registration system attempts to validate the 
digital signature over the entire message in step 464. 
If validation fails (i.e., the decrypted hash value does 
not match the computed message hash or one of the 
certificates in the public key certificate chain has been 
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revoked) , a received-corrupted-application PEM is 
returned to the UA user. The validation failure is 
recorded in the log file in step 462. 

If the validation succeeds, then an application- 
5 received PEM is sent to the OA user in step 466. 

The registration system attempts to validate the 
rights registration information (only simple checks are 
performed) in step 468. If validation fails, a rights- 
application-is-formatted-incorrectly PEM is returned to 
lo-the-UAuserT ■^^mwimwrrreS^liTtHB 
log file (step 462) . 

If the validation of the application information 
was successful, then the following are entered into the 
registration system's work in progress database: the 
as application information, the digital signatures, and the 
public key certificate chains. The entry into the work 
in progress database is recorded in the log file in step 
470. 

The registration system hashes the object's handle 
20 in step 472. It uses this hash to perform a table lookup 
in the hash code/handle server table (step 474) , which 
was previously obtained from the handle server directory. 
The registration system then sends a request-for-pointer- 
information UDP packet to a handle server 58 (Figure 18) 
25 in step 476. 

In step 478, the handle server verifies that the 
handle falls within the set of handles for which hash 
values it is responsible. If it is not in this set, the 
handle server sends an invalid-handle-server-selected 
30 response UDP packet to the registration system (step 
480) . 

If the registration system receives an invalid- 
handle-server-selected response UDP packet, it refreshes 
its hash code/handle server table from the handle server 
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directory (step 482), and the registration system repeats 
steps 472 and 474. 

If the handle server is responsible for the 
handle, it verifies that the handle is present in its 
5 database in step 484. If not, it sends a handle-not-found 
response UDP packet to the registration system (step 
486). 

If the registration system receives a handle-not- 
found response UDP packet, it returns a reguested-object- 
10 is-unavailable PEM message to the UA user (step 488) , and 
the handle lookup failure is recorded in the log file. 
The registration system removes the entry for the 
registration request from the work in progress database 
in step 490. 

15 If the handle server has the handle in its 

database, it returns the pointers associated with the 
handle in a UDP packet to the registration system in step 
492. 

For each pointer returned by the handle server, 
20 the registration system tries to obtain a copy of the 
object. If a copy is successfully obtained from one 
repository 36 (Figure 18) , then the rest of the pointers 
are ignored, if the registration system cannot obtain 
the object from any of the repositories, the registration 
25 system returns an unable-to-obtain-a-copy-of-the-object 
PEM to the UA user (step 494) . The failure to retrieve 
the object is recorded in the registration system's log 
file, and the rights registration entry is removed from 
the work in progress database (step 496) . 
30 I* « pointer does not indicate that RMS 38 (Figure 

18) negotiation is required, the registration system 
ignores the object pointer, if a pointer does indicate 
that RMS negotiation is required (step 498), the 
registration system attempts to obtain the object via the 
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RMS. First, in step 500, the registration system 
connects to the RMS.. 

The RMS returns a random- value tag to the 
registration system in step 502. In step 504, the 
5 registration system sends the following information to 
the RMS: the object's handle, the registrar's digital 
signature over the RMS generated random-value tag, the 
registrar's public key certificate chain, the domain name 
and the port number which will be used by the 

"TO registration system to receive~l-he^>bjecir. 

The RMS validates the digital signature over the 
random-value tag in step 506. If the signature is not 
correct, the SMS sends an invalid-random-value-tag 
response to the registration system in step 494. The 

is registration system logs this error and removes the 

rights registration information from the work in progress 
database (step 496). 

The RMS verifies in step 508 that the registration 
system meets the terms and conditions for the object, if 

20 the registration system does not meet the terms and 

conditions, a reguester-unauthorized-rejection response 
is returned to the registration system (step 494). The 
registration system logs this error and removes the 
rights registration information from the work-in-progress 

25 database (step 496). 

The RMS connects to the repository in step 510, 
and the repository returns a random-value tag to the RMS 
(step 512). 

The RMS sends the following information to the 
30 repository in step 514: the object's handle; the RMS 
digital signature over the repository generated random- 
value tag; the RMS public key certificate chain; and the 
domain name and the port number which are used by the 
registration system to receive the object. 
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The repository verifies the digital signature of 
the RMS over the random-value tag in step 516. if the 
signature is not correct, the repository sends an 
invalid-random-value-tag response to the RMS (step 518) . 
s The RMS logs the error and sends a remote-RMS-error- 
invalid-random-value-tag error to the registration system 
in step 520. The registration system then logs this 
error and removes the rights registration information 
from the work in progress database (step 522). 

*° * n ste P 524, the repository verifies that the RMS 

is allowed to request object transfers for the object. 
If the transfer is not allowed, the repository sends an 
invalid-RMS response to the RMS (step 518) , which 
forwards the response to the registration system (step 

is 520). The registration system logs the error in its log 
file, and the rights registration information is removed 
from the work in progress database (step 522) . 

The repository sends a object-retrieval-is-allowed 
response to the RMS (step 526) , and the repository 

20 disconnects from the RMS (step 528) . 

The RMS forwards the object-retrieval-is-allowed 
response to the registration system (step 530) , and the 
RMS disconnects from the registration system (step 532) . 
The repository connects to the address/port 

25 specified in the original request, and it transmits to 
the registration system the object's handle and the 
object, signed by the repository in step 534. The 
repository then sends a object-has-been-delivered 
confirmation to the RMS (step 536) . 

30 The registration system validates the user's 

digital signature over the object in step 538. If 
validation fails, an invalid-object-digital-signature- 
presented PEM message is returned to the UA user in step 
540. In step 542, the validation failure is recorded in 
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the log file, and the rights registration is removed from 
the works in progress database. 

Steps 286 et seq. (Figure 11) are then followed. 
The registration system prepares an initial receipt in 
5 progress (RIP) record (step 290) . The registration 

system converts the information located in the title and 
claimant name fields in the registration request into the 
title and claimant name fields in the RIP record. The 
following conversions are performed: title words that are 

10 located~in a~stop word TistT are deleted and title wordsT 
that are located in an abbreviated terms list are 
abbreviated. 

The object is placed into the work in progress 
database. A bar-code number is assigned to the 

15 registration request (step 290) . A verify-and-debit 
request, which contains the bar-code number (and other 
RIP record information) is formatted and sent to the 
tracking system in step 292. 

The tracking system verifies the account and 

20 debits the requested amount from the account in step 294. 
If the account is not valid, the tracking system will 
send an invalid-account-number presented message to the 
registration system (step 296). If the account is valid, 
but insufficient funds exist for this transaction (step 

25 298), then the tracking system will send an insufficient- 
funds message to the registration system (step 296) . In 
either error case, the validation failure is recorded in 
the registration system* s log file; the rights 
registration is removed from the works in progress 

30 database (step 282) . 

If the tracking system successfully performed the 
account verification and debit processing, it sends a 
account-is-OK message to the registration system in step 
302. the tracking system prepares an initial RIP record 

35 and places it in its database. 
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The registration system then moves the 
registration request to the examiner queue database in 
step 304. The examiner's workstation now has access to 
this registration request. The examiner uses the 
5 workstation 50 (Figure 18) to view the object on the 
screen, to add his name to the examined by line on the 
application form and to record the class designation for 
the rights registration (step 306). The converted form 
of the author and title (as stored in the RIP record) are 

io also shown to the examiner. 

If the examiner approves the application in step 
308, an examination-is-approved message is sent from the 
workstation to the registration system (step 310) . The 
registration system assigns a registration number (step 

15 312), and the system creates and digitally signs the 
rights registration certificate, which includes the 
registration number and the date on which registration 
was granted (step 314) . The rights registration 
certificate" is sent in a PEM message to the UA user in 

20 step 316. The certificate is archived on the 
registration system. 

If the examination results in the rights 
registration application being rejected, the examiner 
uses the workstation to send a rights-registration- 

25 rejection PEM message to the applicant explaining the 
rejection (step 318). 

If the registration was approved or denied, an 
updated RIP record is forwarded to the tracking system in 
step 320. once the tracking system has added the record 

30 to its database, it sends a RIP-record-update-OK message 
to the registration system (step 322) . 

The registration system moves the registration 
request to the catalog queue database in step 324. The 
cataloged s workstation 57 (Figure 19) now has access to 

35 this registration request. Using a telnet window 
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connected to the cataloging system, the cataloger creates 
the cataloging information (step 326) . When he is 
finished, the workstation sends a finished catalog 
message to the registration system in a step 328. In 
5 step 330, the registration system places a registration- 
application-processing-complete message in the log file. 

Once the registrar has completed its work, the 
object itself may be purged from the files of the 
regist ra r bec ause the digital signature and the existence 
io "of the full object at VVepository 7 are snft icient to 

assure that a valid copy of the object may be obtained at 
any time. This significantly reduces the storage 
requirements at the registrar. 
Software Orr^ r? *H ?T1 

15 The following software packages run on workstation 

42: 

MH is a full featured user agent for 
handling Internet mail. Rather then 
being a single comprehensive program, 
MH consists of a collection of fairly 
simple single-purpose programs to 
send, receive, save, and retrieve 
messages. MH is extensible, other 
user agents may be layered on top of 
the MH executables. The MIME 
extensions provide multiple part 
multiple body type message 
capabilities (e.g., for multimedia 
mail) . 

These tools are used to generate 
private and public keys and user 
certificates. 

The following executables run on the rights user's 
workstation 42: 



MH w/PEM and MIME 
extensions 



PEM administrative 
20 tools 
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submit_registration This tool is used to create and 

submit a rights registration 
application. 

install_ipms This tool will install the MH/PEM 

and submit_registration tools on the 
rights user's workstation. 
The registration and recordation system (RRS) must 
perform the following activities: the RRS must provide 
5 the user interface (as an X-windows client) for rights 
office personnel to view, edit, approve, reject or defer 
rights registration applications; the RRS must provide 
the user interface (as an X-windows client) for rights 
office personnel to view digital objects; the RRS must 
10 support electronic mail transmission and reception; the 
RRS must maintain several queues of the rights 
registration application as it passes through the various 
states of reception, examining and approval/disapproval; 
until the repository is completed, the RRS must save all 
15 of the digital objects received (as a temporary 
repository; until another storage is facility is 
created/ found, the RRS must retain all of the 
registration certificates that have been generated. 

The following software packages run on the UA 

20 host: 

MH w/PEM and MIME MH is a full featured user agent for 
extensions handling internet mail. Rather then 

being a single comprehensive program, 
MH consists of a collection of fairly 
simple single-purpose programs to 
send, receive, save, and retrieve 
messages. MH is extensible, other user 
agents may be layered on top of the MH 
executables. 
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PEM administrative These tools are used to generate 
tools private and public keys and user 

certificates. 

The following executables run on the rights user's 
workstation: 

5 Program/ Daemon Performs 

receive_application When sendmail receives a message 

addressed to 

" submit_registration" , it will 
pass the message to 
receiv*_applioation , which will 
perform the initial 
verifications on the message. 

retrieve_object If the object was not included 

in the original message, this 
program attempts to retrieve the 
object. This program is executed 
periodically by cron. This 
program is also responsible for 
performing time-out functions 
(for retrieving the object) . 

prepare_initJRIP_record This program, which is started 

by receive__applieation or 
retrieveobject is used to 
create and queue the initial RIP 
record, which will be sent to 
the tracking system. 



xmit_files_to_the 
10 tracking system 



This program, started by cron, 
is used to send already 
formatted files to the tracking 
system. 
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get_files_from_the 
tracking system 

process_lnit_RIP_response 
view_application 



applicationjjueue_server 
send_resp_to_applicant 



- 68 - . 

This program, started by cron, 
is used to retrieve response 
files from the tracking system. 

If get_f iles_f rom_the tracking 
system receives an initial RIP 
record response, it invokes this 
program to handle the response 
from the tracking system. 

This user application is invoked 
by the Examiner to view, edit, 
accept or reject the rights 
application. This program also 
displays the digital objects to 
the Examiner. The Cataloger may 
also use this program to view 
the application and associated 
digital object. 

This is the * back-end" process 
that manages application/object 
requests received from user 
programs (i.e. 
viev_applicat ion . ) 

This program, which is invoked 
by vi*v_applioation, is used to 
send the application approval/ 
and certificate or the 
application rejection to the 
rights applicant. 
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update_RIP_record 



process_updatejRlP_resp 



install rrs 



This program, which is invoked 
by viev_application, is used to 
create an updated RIP record, 
which will be transmitted to the 
tracking system, using 
xait_f iles_to_the tracking 
system. 

If get_f iles_from_the tracking 
system receives^ an update THP~ 
record response, it invokes this 
program to handle the response 
from the tracking system. 

This program is used to install 
the additional configuration 
files and software required for 
the RRS system. 



retr ieve_ob j ect 
5 prepare_init_RIP_record 

xmit_files_to_the tracking system 

get_files_from_the tracking system 

process_init_RIP_response 

view_application 
o application_queue_server 

send_resp_to_applicant 

updateJIIPjrecord 

process_update_RIP_resp 

install rrs 
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Qbtflipinq fl Digital Object from a Rgpngifrgry 

This section describes how a user may obtain an 
account and retrieve digital objects from repositories. 

Before a user can retrieve any objects for which 
5 payment is required, the user must first establish an 
account with a payment server system 702 on the network 
(Figure 25) • This system will be used to create new 
accounts, debit and credit user accounts, and interface 

wit:h L one or more credlt se FY i ^ e c<Br ^ e ?? 704 v Pa yment 
10 servers have the following attributes: 

Payment servers must be qualified; it must be 
possible to verify that a payment server is valid. 
This may be accomplished by establishing payment 
server distinguished names; if a signed message is 
15 received from a server with a payment server 

distinguished name, then the payment server is 
valid. 

Payment servers may charge users for establishing 
accounts. 

20 Users may request server information (including 

establishing account charges) from a server before 
attempting to set up a new account. 
The following steps (Figure 26) illustrate how a 
user can establish a new account with a payment server. 

25 A user must have a certificate and a valid credit card 
number in order to establish an account. 

The user (or his software agent) formats (706) a 
setup-new-account message containing the 
following: 

30 The user's credit card number or other credit 

information; 

Other identifying information, such as a 
street address, phone number; 
Requested credit amount; 
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A list of valid signatures (either public key 
certificates and their associated certificate 
chains or distinguished names) for people 
allowed to charge to the account. 
Optional category of use (e.g. this account 
is used to retrieve video objects only.) 
Optional time limit (e.g. this account will 
be valid until December 31 , 1995.) The 
payment server will normally keep an account 
active as long as a minimum line of credit is 
available. 

The setup-new-account message is digitally signed 
by the person establishing the account, and the 
signed message is sent (708) to the payment server 
with the above information. 

The payment server verifies the signature on the 
received message (710) . If the signature is 
invalid, the payment server sends an invalid- 
signature message to the user's system (712). 
Optionally, it may identify a maximum allowed 
credit limit. 

If the signature is valid, using standard 
electronic credit card checking protocols or other 
methods as appropriate, the payment server 
electronically verifies the credit card number or 
other credit information, and requested credit 
line with a credit card service center or other 
credit authority (714). 

If the credit card number or other credit 
information is not valid (718), the payment server 
will send an invalid-credit-card message to the 
user's system (720) . 

If the requested credit limit is too high, the 
payment server will send a requested-credit-limit- 
is-too-high message to the user's system. 
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The payment server will verify that the other 
authorized user's identities are valid (722). If 
any are invalid, an invalid-authorized-user- 
specified message is sent (724) to the user's 
5 system. 

The payment server assigns an account number to 
the user (726) and stores the account information 
in a database for later use. 

The P a y»ent server formats a new-account-response 
0 message (728) containing the following; 

Account Number 
Credit Limit Amount 
Time Limit 
Categories of Use 
5 List of authorized users (public key 

certificates plus the certificate chains.) 
The requesting system or user's public key 
certificate chain, which will be used to 
verify the requestor's identity. Other less 
o efficient methods can also be used, e.g. the 

payment server could be given sufficient 
information (the distinguished name) about 
the user to obtain the certificate chain from 
another database. 
5 The payment server signs the formatted message and 

sends it to the user's system. Optionally, the 
user may be charged a fee for establishing this 
account and for maintaining it. 
The user's system encrypts and stores (730) the 
D received signed message. This account data will 

be submitted with any activity that may be billed. 
Retrieving from a Repository rsinnie T e m> fl ap<j 
Conditions) 
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Once an account is established, the user may 
retrieve an object from the repository by the following 
steps (Figures 25 and 27) . 

The system requesting the digital object obtains 
(740) the hash code/handle server table from the 
handle server directory 59. This is done during 
the system's initialization. 
A user (or more likely, his software agent) 
obtains a handle 743 for an object (742) . The 
handle may be obtained as part of a result of a 
bibliographic search or be provided by some other 
electronic means such as an electronic reference 
list in another object, or by scanning a barcoded 
sequence on paper. The system that is retrieving 
the digital object is referred to as the 
requesting system 745. 

Once the handle is obtained, the system that 
retrieves the object "hashes" the object's handle 
and uses this hashed value to perform a table 
lookup in the hash code/handle server table 744. 
The requesting system sends a request-for-pointer- 
information UDP packet 748 to the handle server. 
One or more pointers, once returned, identifies 
the network location of the one or more 
repositories (if one is associated with the 
object) and one or more rights management system, 
if one is associated with the object. This 
strategy assures a random distribution of handle 
server requests among many handle servers 
distributed on a network without a central nodal 
point in the system (for reliability). 
The handle server verifies that the handle falls 
within the set of handles for whose hash values it 
is responsible 750. 
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If it is not in this set, due to some dynamic 
system change or error condition, the handle 
server sends an invalid-handle-server-selected 
response UDP packet to the requestor 752. 
If the requesting system receives an invalid- 
handle-server-selected response UDP packet, it 
refreshes its hash code/handle server table from 
the handle server directory, and the requesting 
Sy8t ^ n _ repeat8 Prior steps. This will typically 
be needed only if the table has changed between 
the time the table was downloaded and the actual 
request was made. 

If the handle server is responsible for the 
handle, it verifies that the handle is present in 
is its database 756. If not, it sends a handle-not- 

found response UDP packet to the requesting system 
758. 

If the requesting system receives a handle-not- 
found response UDP packet, it informs (760) the 
user that it is unable to retrieve the object. 
An object may be stored in several repositories. 
Multiple pointers to these repositories may be 
returned to the requesting system. For each 
pointer returned by the handle server, the 
requesting system uses the pointer to attempt to 
obtain a copy of the digital object 762. if a 
copy is successfully obtained from one repository, 
the rest of the pointers will generally be 
ignored. If the requesting system cannot obtain 
the object from any of the repositories, it 
informs the user that it is unable to retrieve the 
object 764. 

For retrieval purposes, the requesting system 
establishes a connection to the repository 766, 
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which takes the form of a small set of 
transactions. 

The repository may examine the calling network 
address or the requesting system in order to 
5 determine if the repository is being inundated 

with requests from one system. If the repository 
determines that it is being bombarded, the 
repository may disconnect from the requesting 
system and refuse to accept additional requests 
10 for a p^YibdT of time 768. 

Normally, however, the repository returns a 
random-value tag to the requesting system 770. A 
flag indicating if payment is required to obtain 
"Terms and Conditions" is included. 
15 The requesting system needs the object's "Terms 

and Conditions" before the object can be 
retrieved. The requesting system signs and sends 
the following request-terms-and-conditions message 
772 to the repository: 
20 the object's handle; 

the requesting system or user's digital 
signature over the repository generated 
random-value tag; 

the requesting system or user's public key 
25 certificate chain, which will be used to 

verify the requestor's identity. Other less 
efficient methods can also be used, e.g. the 
repository could be given sufficient 
information (the distinguished name) about 
30 the user to obtain the certificate chain from 

another database. This is needed in the 
event the repository needs to bill for 
providing the Terms and Conditions; 
a unique tag, assigned by the requesting 
35 system; 
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account information, previously signed by the 

payment server. 
The repository verifies the digital signature of 
the requestor over the repository generated 
5 random-value tag 774. If the signature is not 

correct, the repository sends an invalid-random- 
value-tag response to the requesting system. The 
requesting system should log this error. 
The repository verifies the payment server's 
10 signature over the account information 778. If 

the signature is not correct, the repository sends 
an invalid-account-information response to the 
requesting system. The requesting system should 
log this error. 

is The repository retrieves the Terms and Conditions 

associated with the specified handle 790. If no 
object is associated with the handle, the 
repository sends an object-not-found message to 
the requesting system. The requesting system 
20 should log this error. 

Otherwise, the repository signs the "Terms and 
Condition" message and sends 792 it to the 
requesting system, including: 
The object! zed list of 
25 terms/conditions/rights, along with the 

charge associated with each object and a 
status flag showing if the 
term/condition/right is mandatory; 
The user-assigned unique key, which was 
30 received in the request-terms-and-conditions 

message; 

Either the original random-value tag or 
possible a new random-value tag, generated by 
the repository. This is to avoid play back 
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protection in the event the object identified 
by the handle is retrieved later* 
The requesting system verifies the 
repository's signature over the received 
"Terms and Conditions" message 794. If the 
signature is invalid, the error is logged. 
The user selects the terms and conditions desired 
796, including the number of terms (e.g., A user 
may buy the right to make 5 copies of the object 
or to perform it ten times) . The requesting 
system uses this information to create the 
retrieve-object message, including: 
the object's handle 798; 

the repository generated random value tag; 
a list of the accepted "Terms and 
Conditions", including the quantity of each, 
- where applicable; 

the user's account information, which was 
originally signed by the payment server; 
the requesting system or user's public key 
certificate chain, which will be used to 
verify the requestor's identity. Other less 
efficient methods can also be used, e.g. the 
repository could be given sufficient 
information (the distinguished name) about 
the user to obtain the certificate chain from 
another database. 

the domain name and the port number which are 
used by the requesting system to receive the 
object. 

limitations, if any, on the object by the 
requesting system (e.g. maximum object size 
it can receive) 

The entire message is signed by the requestor. 

This is similar to signing a credit card slip. 



The repository verifies the digital signature of 
the requestor over the random- value tag 800. If 
the signature is not correct, the repository sends 
an invalid-random-value-tag response to the 
requesting system 802. The requesting system 
should log this error. 

The repository establishes a connection to the 
payment server, 804. 

The P_ a y?_ ent _ server _ retur P s a random-value tag to 
the repository 806. 

The repository formats a debit-account message 
808, including: 

The retrieve-object message, as received by 

the repository and signed by the requestor; 

The random value tag received from the 

payment server; 

The repository's public key certificate 
chain, which will be used to verify the 
repository's identity. Other less efficient 
methods can also be used, e.g. the payment 
server could be given sufficient information 
(the distinguished name) about the user to 
obtain the certificate chain from another 
database. 

The repository signs the retrieve-object and 
random-value portion of the message. The 
repository sends the debit-account message to the 
payment server system. 
The payment server system validates the 
repository's signature over the debit-account 
message 810. If the signature is invalid, the 
payment server logs the error and sends a invalid- 
vendor-signature message to the repository. 
The payment server system then validates the 
requestor's signature over the contained retrieve- 
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object message 812. If the signature is invalid, 
an invalid-requestor-signature message is sent to 
the repository. 

The payment server validates the account 
s information sent to it and verifies that the 

account is valid. If the requestor is not a valid 
user of the account, a invalid-user-for-account 
message is sent to the repository, and the payment 
server logs the event. 
10 Otherwise, the~p¥ymeht server, using already 

existing electronic credit verification methods, 
verifies that the amount may be charged to the 
account 816. 

If the credit check is not successful, the 
is appropriate error message (e.g. "credit Line is 

insufficient", "Credit Card has Expired") is 
logged and sent to the repository. 
Otherwise an account-has-been-debited message is 
signed by the payment server and sent to the 
20 repository 818. 

The repository connects to the address/port 
specified in the request, and it transmits 820 to 
the requesting system: 

the object's handle; 

the total amount debited from the account; 
the object, signed by the repository; 
portions of the relevant terms and 
conditions, if appropriate. 
aetriev i pg Vrv ^ er Non-simm* Tam,* „„„ sm ditians 

The following steps are followed for retrieving an 
object under non-simple terms and conditions. 

If the user does not know the current terms and 
conditions associated with the object, steps 740 through 
794 (Figures 27 and 28) are first performed, if the user 
determines that the terms and conditions returned by the 
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repository are not appropriate by themselves, then 
additional negotiations with the RMS associated with the 
digital object are required. 

If a user already knows that negotiations are 
5 required with an RMS, but the RMS associated with the 
digital object is not yet known, then the user's system 
must perform steps 740 through 764 (Figure 27). 

Otherwise, referring to Figure 29, the requesting 

system establishes a connection to the RMS 830. 
10 The RMS returns a random- value tag to the 

requesting system 832. 

The requesting system sends the following 
information to the RMS: 

the object's handle; 
15 the requestor's digital signature over the 

RMS generated random-value tag; 

the requestor's public key certificate chain; 

the domain name and the port number which 

will be used by the requesting system to, 
20 receive the object; 

a random value tag, assigned by the 

requesting system; 

the accounting data previously signed by the 
payment server. 

25 the RMS validates the digital signature over the 

signed random-value tag 836. If the signature is 
not correct, the RMS sends an invalid-random- 
value-tag response to the requesting system. The 
requesting system logs this error. 

30 The repository verifies the payment server's 

signature over the account information 838. If 
the signature is not correct, the repository sends 
an invalid-account-information response to the 
requesting system. The requesting system should 

as log this error. 
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The rms enters into a mixed initiative dialog 840 
with the user to determine what terms and 
conditions are mutually acceptable, if any. This 
may also entail human interaction. 
The RMS connects to the repository 842, and the 
repository returns a random-value tag to the rms 
844. 

The rms sends 846 the following information to the 
repository: 

the object's handle; "' 
the RMS's digital signature over the 
repository generated random-value tag; 
the RMS public key certificate chain; 
the domain name and the port number which are 
used by the requesting system to receive the 
object; 

the account information, previously signed by 
the payment server. 
The repository verifies the digital signature of 
the RMS over the random-value tag 848. if the 
signature is not correct, the repository sends an 
invalid-random-value-tag response to the RMS. The 
RMS logs the error and sends a remote-RMS-error- 
invalid-random-value-tag error to the requesting 
25 system. The requesting system logs this error. 

The repository verifies that the RMS is allowed to 
request object transfers for the object, if the 
transfer is not allowed, the repository sends an 
"invalid RMS- response to the RMS, which forwards 
30 the response to the requesting system. The 

requesting system logs the error in its log file. 
The repository establishes a connection to the 
payment server 850. 

The payment server returns a random-value tag to 
35 the repository 852. 
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The repository formats a debit-account message 

854, including: 

The retrieve-object message, as received by 
the repository and signed by the requestor; 
5 The random value tag received from the 

payment server; 

The repository's public key certificate 
chain, which will be used to verify the 
repository's identity. Other less efficient 
io methods can also be used, e.g. the payment 

server could be given sufficient information 
(the distinguished name) about the user to 
obtain the certificate chain from another 
database. 

15 The repository signs the retrieve-object and 

random-value portion of the message. 
The repository sends the debit-Account message to 
the payment server system. 
The payment server system validates the 

20 repository's signature over the debit-account 

message. If the signature is invalid, the payment 
server logs the error and sends a invalid-vendor- 
signature-message to the repository. 
The payment server. system then validates the 

25 requestor's signature over the contained retrieve- 

object message. If the signature is invalid, an 
invalid-requestor-signature message is sent to the 
repository. 

The payment server validates the account 
30 information sent to it and verifies that the 

account is valid. If the requestor is not a valid 
user of the account, a invalid-user-for-account 
message is sent to the repository, and the payment 
server logs the event. 
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Otherwise, the payment server, using already 

existing electronic credit verification, verifies 

that the amount may be charged to the credit card 

associated with the account 860. 

If the credit check is not successful, the 

appropriate error message (e.g. "Credit Line is 

insufficient", "Credit Card has Expired") is 

logged and sent to the repository. 

Otherwise an account-has-been-debited message is 

signed by the payment server and sent to the 

repository 862. 

The repository sends 864 a object-retrieval-is- 
allowed response to the RMS, and the repository 
disconnects from the RMS. 

The RMS forwards 866 the object-retrieval-is- 
allowed response to the requesting system, and the 
RMS disconnects from the system. 
The repository connects to the address/port 
specified in the request, and it transmits to the 
requesting system 868: 

the object's handle; 

the total amount debited from the account; 

the object, signed by the repository. 
The repository sends a object-has-been-delivered 
confirmation to the RMS 870. 

All of the transactions tracked and recorded in 
the above system could be used to feed an automated 
accounting system for a variety of purposes. 
Retrieving Registration Information 

The public access system will be based on a 
commercial DBMS. Queries to this system will be 
performed using standard database techniques via a direct 
connection, or over a network. 

Other embodiments are within the scope of the 
following claims. 
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What is claimed is: 

1. A method of managing digital objects in a 
network, each of the digital objects comprising a set of 
sequences of digits and having an associated identifier 

5 which is unique across the network, the method comprising 
storing the digital objects at locations 
accessible in the network using a storage technique which 
renders the digital objects secure against unauthorized 
access, 

io storing pointer information which associates each 

digital object identifier with a pointer indicating the 
location of the stored digital object in the network, and 

for each of the digital objects, storing, 
separately from the digital object, validation 

15 information sufficient to permit a determination whether 
a purported instance of a digital object is identical to 
the original instance* 

2. The method of claim 1 further comprising 
permitting an authorized user to have access to 

20 the validation information, using the digital object 

identifier, to determine whether a purported instance of 
a digital object is identical to the original instance, 

3. The method of claim 1 wherein the validation 
information comprises a digital signature over the 

25 digital object. 
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4. A method of managing reference information 
about digital objects in a network , each of the digital 
objects comprising a set of sequences of digits and 
having an associated identifier which is unique across 

5 the network, the method comprising 
storing the digital objects, 
storing reference information for each of the 
digital objects, and 

storing validation information for each of the 
10 digital objects which is substantially smaller in size 
than the corresponding digital object and which enables a 
determination of whether a purported instance of a 
digital object is identical to the original instance. 

5. The method of claim 4 further comprising 

is permitting authorized users to have access to the 

reference information using the unique identifier. 

6. The method of claim 4 wherein the reference 
information comprises information concerning at least one 
of the following: registration of rights in digital 

20 objects; accesses to and uses of digital objects; the 
terms and conditions for access and use of digital 
objects; the ownership and licensing of rights to digital 
objects; links between different digital objects. 
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7. A method of storing digital objects in a 
network, each of the digital objects comprising a set of 
sequences of digits, the method comprising 

generating an identifier for each of the digital 
objects which is unique across the network, 

storing the digital objects in the network, 

storing pointer information that associates each 
identifier of a digital object with the location of the 
digital object in the network, 

generating verification information for each of 
the digital objects, the verification information being 
sufficient to determine whether a purported instance of 
the digital object is identical to the original instance, 
and 

storing the verification information separately 
from the digital object. 

8. The method of claim 7 wherein the pointer 
versus identifier information is stored in multiple 
servers on the network, and the identifiers are generated 
in a manner to distribute the pointer versus unique 
identifier information relatively evenly among the 
servers . 

9. The method of claim 8 wherein the distribution 
of pointer versus unique identifiers to the multiple 
servers is based on a hashing algorithm. 
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10. A method for enabling users of a network to 
access digital objects stored in the network , each of the 
digital objects comprising a set of sequences of digits 
and having an associated identifier which is unique 
across the network, the method comprising 

providing multiple pointer servers each of which 
accepts identifiers of a subset of the digital objects 
and returns corresponding pointers to the locations of 
the digital objects in the network, and 

providing a directory server which accepts 
identifiers of any of the digital objects and returns the 
locations of the pointer servers which accept those 
identifiers. 

11. A method of applying for registration of 
rights in digital objects comprising 

storing the digital objects in a network, 

generating validation information for each of the 
digital objects sufficient to determine whether a 
purported instance of a digital object is identical to 
the original, 

generating a unique identifier for each of the 
digital objects, 

associating with each of the unique identifiers a 
pointer to the location of the digital object in the 
network, ahd 

submitting to a registering authority, an 
application for registration of rights including the 
validation information and the unique identifier. 
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12. A method of enabling holders of rights in 
digital objects to control terms and conditions under 
which they are accessed by users in a network , comprising 

storing the digital objects in the network in a 
5 manner that permits only authorized access, 

storing, in the network, information about terms 
and conditions for access to each digital object, 

inaking the information about terms and conditions 
available to a user in connection with a request for 
10 access to a digital object, 

enabling the user to indicate assent to the terms 
and conditions, and 

permitting access to the user only upon the user 
indicating assent to the terms and conditions. 

is 13. A method of enabling holders of rights in 

digital objects to control terms under which rights in 
the digital objects may be granted to others, comprising 
storing, in the network, terms and conditions for 
licensing rights, 

20 providing information on terms and conditions 

pertaining to works or other information or material that 
the digital object may be based on or incorporate, 

making the terms and conditions available to 
potential rights holders and users, as appropriate, upon 

25 request via the network, 

enabling the potential rights holder and the 
current rights holder to interact via the network to 
reach agreement on terms and conditions for grant of 
rights, 

30 storing, in a recordation server on the network, 

information identifying grants of rights for digital 
objects on the network. 
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14. A method to permit a user to comply with 
terms and conditions of access to digital objects stored 
in a network, each of the digital objects comprising a 
set of sequences of digits and having an associated 
5 identifier which is unique across the network, the method 
comprising 

storing in the network information which 
associates with each of the unique identifiers, a pointer 
to a rights management system including a terms and 
10 conditions server containing terms and conditions, 

providing to the user in response to presentation 
of a unique identifier the pointer to the terms and 
conditions server, 

providing to the user in response to presentation 
15 of the pointer, terms and conditions information, 

enabling the user to indicate assent to the terms 
and conditions, 

in response to the assent, permitting the user to 
access the digital object including performance of the 
20 object. 
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15. A method for maintaining a record of 
information concerning digital objects stored on a 
network, each of the digital objects comprising a set of 
digits and having an associated identifier which is 
s unique across the network, the method comprising 

storing the digital objects on the network in a 
manner that restricts unauthorized access to and 
transactions associated with the digital objects, 

providing a reference service on the network, 
10 separate from the storage of the digital objects, for 
recording information about accesses to and transactions 
associated with the digital objects, 

recording in the reference service information 
about accesses to and transactions associated with the 
15 digital objects, and 

permitting access to the records of the reference 
service to authorized users. 
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16. A method for managing registration of claims 
to rights in digital objects and any works or other 
information or material that the object may be based oh 
or incorporate, comprising 

storing, in a repository which is accessible on a 
wide area network, copies of the digital objects, in a 
manner that enables only authorized accesses to the 
digital objects and permits verification that the stored 
digital objects have not been subjected to unauthorized 
alteration, 

at an information and reference server which is 
accessible on the network at a different network address 
from the repository, providing registration services 
including receipt via the network of registration 
requests and delivery via the network of registration 
certifications, and 

accessing, from the repository via the network, 
the objects for use in providing the registration 
services. 

17. The method of claim 16 further comprising 
enabling owners of rights in digital objects to 

deposit copies of the digital objects in the repository 
via the network. 

18. The method of claim 17 further comprising 
providing a service, accessible on the network, 

for generating a unique handle for each digital object. 

19. The method of claim 18 wherein 
the handle for a digital object is unique both 

across the network and over time. 
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20. The method of claim 18 further comprising 
providing a service, accessible on the network, 
for generating the handle and locating the pointer 
associated with the handle for a digital object. 

5 21. The method of claim 18 wherein the handle is 

used to obtain a pointer to the network location of an 
accessible copy of the digital object. 

22. The method of claim 18 wherein the handle 
comprises a pointer to the network location of 

10 information concerning obtaining authorization to use the 
digital object. 

23. The method of claim 18 wherein the service is 
provided at multiple different locations on the network. 

24. The method of claim 20 wherein the service is 
is provided at multiple different locations on the network. 

25. The method of claim 18 wherein the handles 
comprise character strings associated with the servers 
which generated them. 

26. The method of claim 21 further comprising 
20 providing a service, accessible on the network, 

for providing the pointer in response to a handle. 

27. The method of claim 26 wherein there are 
multiple servers providing the service, each serving a 
portion of the handle space. 
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28. The method of claim 18 wherein there are 
multiple handle generation servers that may generate 
handles independently. 

29. The method of claim 16 further comprising 
storing information concerning terms and conditions for 
access to and use of the digital objects. 

30. The method of claim 29 wherein information 
concerning simple terms and conditions is stored in the 
repository. 

31. The method of claim 16 wherein additional 
information concerning non-simple terms is held in a 
rights management system. 

32. The method of claim 18 wherein each of the 
handles may be used to obtain one or more pointers to a 
location or locations on the network where a copy of the 
digital object to which the handle is assigned is 
accessible. 

33. The method of claim 32 wherein each of the 
handles may be used to obtain one or more pointers to on< 
or more rights management system in which information 
concerning non-simple terms is held and where rights 
negotiation may be carried out. 

34. The method of claim 18 wherein hash values 
are computed on the handles and the hash values are 
distributed among multiple handle servers, each handle 
server having a table which associates handles with 
pointers. 
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35. The method of claim 16 further comprising 
responding to requests, received via the network, for 
copies of the stored digital objects. 

36. The method of claim 35 further comprising 
5 determining whether the requests for copies are 

authorized. 

37. The method of claim 16 further comprising 
providing multiple repositories. 

38. A method for providing a repository for use 
10 in network based regulation of claims in rights in 

digital objects comprising 

storing copies of the digital objects in a 

repository accessible on the network, the copies being 

stored in a secure manner that precludes other than 
15 authorized access and that permits subsequent 

verification that there have been no unauthorized changes 

to the objects, 

providing handles for the digital objects, each 

handle being unique across the network and over time, 
20 each handle including information sufficient to locate a 

copy of the digital object on the network, and 
in connection with actions pertaining to 

regulation of claims in rights in the digital objects, 

using the handles to obtain authorized access to the 
25 digital objects. 

39. The method of claim 38 wherein the actions 
include registration of claims in the rights. 
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40. The method of claim 39 wherein the actions 
include obtaining copies of the digital objects in 
exchange for compensation. 

41. A network-based method for managing 

5 compensation for licensing of rights and other operations 
in digital objects, comprising 

storing, in a recordation system available to 
authorized access on the network, information identifying 
the ownership of rights in digital objects, 

10 receiving, at a rights management system available 

on the network, requests for rights in digital objects 
were the terms and conditions have not been stipulated in 
the properties record, and 

in response to the requests for rights, issuing, 

15 from the rights management system to the recordation 

system via the network, requests to record information or 
transfers of rights in and other information pertaining 
to the digital objects and in works or other information 
or material on which the object may be based or 

20 incorporate. 

42. The method of claim 41 wherein the rights 
comprise exclusive rights. 

43. The method of claim 41 further comprising 
recording the transfer of rights in the recordation 

25 system in a manner which is secure against alteration. 

44. The method of claim 41 wherein the request 
for transfer of rights is associated with a commitment to 
compensate the owner of the rights. 
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45. A method for compensating owners of rights in 
digital objects stored in a network for access to the 
digital objects by users via the network, comprising 

storing on the network information associated with 
5 the digital objects and identifying the terms and 

conditions on which a user may have access to the digital 
objects via the network, 

in connection with a request by a user for access 
to a digital object, fetching and providing to the user 
10 the terms and conditions, and 

construing an action taken by the user in 
connection with requesting access to the digital object 
as agreement with the terms, and charging the user 
accordingly. 

is 46. A method for managing handles for digital 

objects in a computer network comprising 

including in the handle an indication of a local 
naming authority having control over generation of a 
subset of all global generated handles, and 

20 including in the handle a string which is locally 

unique with respect to digital objects for which 
generation of handles are controlled by the local naming 
authority. 

47. A method for managing generation of handles 
25 for digital objects in a computer network comprising 

maintaining local naming authorities that control 
generation of handles for digital objects, the handles 
being a subset of all of the handles generated globally, 
and 

30 maintaining a global naming authority that 

controls the naming of the local naming authorities. 
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48. A method for managing handles for digital 
objects in a computer network comprising 

managing some -of the handles to be globally 
publicly accessible, and 
5 managing some of the handles to be only locally 

and privately accessible. 

49. A method of managing access to digital 
objects in repositories comprising 

managing deposit of a digital object by accepting 
10 and storing the digital object and arranging for the 
generation and storage of an associated handle for the 
object, and 

managing access to the digital object by a 
accepting and receiving a service request which includes 
15 a handle. 

50. A system of managing digital objects in a 
network comprising 

a system of repositories which accept f store, and 

make disseminations of digital objects and portions of 
20 digital objects in response to requests received from any 

arbitrary location in the network, 

a system of handle servers which provide services 

in connection with handles for digital objects stored in 

the repositories, 
25 a system of naming authorities which controls 

generation of handles on a global and local basis to 

assure locally unique and globally unique handles for 

digital objects. 



WO 97/43717 



PCT/US97/07834 



1/28 



o 

T- 

©■ 




-1042 




CO \ 


Q£ \ 


a: \ 


Lit \ 


VE 


£ ) 


J 




LU / 


CO f 


to I 


I- I 


y \ 


EN 


o 1 


S J 






Ir 


[PA 



o 

u. 
z 



o 

S CO 
5 LUX • *-HO i 



Q 
O 

uj22 

!rp 

5SQ<LU 





o 

2 

CO 

»- 

X 
O 

cr 



z 

o 

I- 

o 

s 

z 

2 



\ 

a: 

UJ 

CO 
3 



V 
a: 

Ui 
Q 
-J 
O 
X 

I 

cr 



z 
g 

i 

z 

2 



O 

S 



z 
o 
F= 



o 



CO 

z 
o 

E 
a 
z 
o 
o 

CO 
5 

UI 



SUBSTITUTE SHEET (RULE 26) 



WO 97/43717 



PCT/US97/07834 




SUBSTITUTE SHEET (RULE 26) 



WO 97/43717 



PCT/US97/07834 



3/28 . 



DIGITAL 
SIGNING 



112 

DISTINGUISHED 
NAME 



-110 



108 



CERTIFICATE 



r 



KEY 
GENERATOR 



PRIVATE KEyViOO 



OBJECT 



102 



HASHING 
FUNCTION 

1 

104 



I 



ENCRYPTION 
ALGORITHM 



106 



DIGITAL 
SIGNATURE 

1 

105 



VERIFICATION 



CERTIFICATE 



112. 



DISTINGUISHED 
NAME 



| PUBLIC KEY> - -1Q8 



OBJECT 



102 



HASHING 
FUNCTION 

H 

107 



-110 



ENCRYPTION 
ALGORITHM 

T 

106 



DIGITAL 
SIGNATURE 



FIG. 3 



SUBSTITUTE SHEET (RULE 26) 



WO 97/43717 



PCT/US97/07834 



4/28 



INTERNET SOCIETY 



INTERNET POLICY 
REGISTRATION AUTHORITY 



z 



POLICY 
CERTIFICATE 
AUTHORITY 



L 



-116 



I 



WELL-KNOWN 
PUBLIC KEY 



POLICY 
CERTIFICATE 
AUTHORITY 



-116 



5 





—114 




— 114 






CERTIFICATE 




CERTIFICATE 




CERTIFICATE 




AUTHORITY 


• • • 


AUTHORITY 




AUTHORITY 





V////////////A 



zzzzzzzzzzzzzz. 



DIST NAME 
PUBLIC KEY 



110 



FIG. 4 



SUBSTITUTE SHEET (RULE 26) 



WO 97/43717 



PCT/US97/07834 



5/28 - 



VARIABLE LENGTH STRING DEFINED 
ON A PER COUNTRY BASIS 


COUNTRY 
CODE 


/ 134 


T 

132 


130 




FIG. 5 





SERIAL 
NUMBER 

1 

144 

) 
130 



TIMESTAMP 



T 

142 



SUBZONE N 



T" 

140 



SUBZONE 1 



FIG. 6 



r 

140 



.HANDLE 



.US 



HANDLE 
SERVER 
#1 



58 





HANDLE 




HANDLE 




HANDLE 




SERVER 




SERVER 


• • • 


SERVER 




#2 




#3 




#N ! 



0 K 

^ r. 

150 



149 



K+1 M M+1 N 

HASH CODE SPACE 



FIG. 7 



SUBSTITUTE SHEET (RULE 20) 



WO 97/43717 



PCT/US97/07S34 



6/28 

SYSTEM READS HASH * 
RANGE FROM HANDLE |— 170 
SERVER DIRECTORY 



SYSTEM OBTAINS HANDLE] — 172 



SYSTEM GENERATES 
HASH CODE FOR HANDLE 



I 



-174 



SYSTEM FINDS DOMAIN 
NAME OF HANDLE SERVER 
FROM HASH TABLE 



-176 



SYSTEM SENDS HANDLE _ < 78 
TO HANDLE SERVER ' 



180 



HANDLE SERVER" 
HAS POINTER FOR 
HANDLE 

NO 



HANDLE SENT 
TO WRONG HANDLE 
SERVER 
? 



NO 



184 



HANDLE SERVER 
RETURNS 
"HANDLE NOT FOUND" 



YES 



HANDLE SERVER 
RETURNS POINTER 



YES 



182 

( 



HANDLE SERVER 
RETURNS 
"NOT RESPONSIBLE" 



FIG. 8 

SUBSTITUTE SHEET (RULE 26) 



WO 97/43717 



7/28 



PCT/US97/07834 



APPLICANT MAKES 
OBJECTS AVAILABLE 
TO OWN SYSTEM 



-60 



APPLICANT PLACES 
OBJECT IN A 
REPOSITORY 



—70 



z 



APPLICANT RUNS REGISTRATION 
PROGRAM AND FILLS OUT 
TEMPLATE 



-62 



T 



APPLICATION & OBJECT'S HANDLE 
ELECTRONICALLY MAILED TO 
REGISTRATION SYSTEM 



— 64 



I 



REGISTRATION SYSTEM CHECKS 
APPLICATION 



66 




72 



REGISTRATION 
SYSTEM RETRIEVES 
OBJECT FROM 
REPOSITORY 



REGISTRATION SYSTEM K 68 
VERIFIES OBJECT NOT 
CORRUPTED 



I 



RIP CREATED & SENT 
TO TRACKING SYSTEM 



—74 



I 



TRACKING SYSTEM 
VERIFIES ACCOUNT 



I 



—76 



EXAMINER ACCESSES 
APPLICATION TO 
OBJECT THROUGH 
WORKSTATION 



—78 



REGISTRATION SYSTEM ASSIGNS 
NUMBER AND SENDS CERTIFCATE 
TO APPLICANT 



-80 



FIG. 9 



UPDATED RIP SENT TO TRACKING SYSTEM] "" 82 



SUBSTITUTE SHEET (RULE 2$ 



WO 97/43717 



PCT/US97/07834 



8/28 



1 1 

1 ftkl 
| UN 






CATALOGl 
SYSTEK 




W/S 












CM 



o 
m 



in' 





to 

— 


TRACKING 
SYSTEM 














CD 

LI- 



SUBSTITUTE SHEET (RULE 26) 



WO 97/43717 



9/28 



PCT/US97/07834 



APPLICANT GENERATES DIGITAL 
SIGNATURE FOR DOCUMENT 



—250 



APPLICANT MAKES SIGNATURE, 
DOCUMENT & KEY AVAILABLE TO UA 



—252 



UA FILLS OUT & SIGNS 
REGISTRATION APPLICATION 



—254 



UA SENDS MESSAGE TO REGISTRATION 
SYSTEM VIA PEM/MIME 



— 256 



REGISTRATION SYSTEM RECORDS 
MESSAGE RECEIPT 



—258 



NO 




262 



SEND MESSAGE 

TO UA & 
RECORD FAILURE 



RECEIPT CONFIRMATION 
SENTTOCUA 



— 266 




INFORMATION ENTERED IN REGISTRATION 
SYSTEM DATABASE & RECORDED IN LOG 
" 1 1 



274 



FIG. 11A 



SUBSTITUTE SHEET (RULE 29 



WO 97/43717 



PCT/US97/07834 



10/28 




280 

I 

SEND 
DOCUMENT 
TOCUA 



282 

L 



REMOVE ENTRIES 
IN DATABASE 
& 

RECORD FAILURE 



PLACE DOCUMENT 
IN ACQUISITION QUEUE 



I 



—288 



REGISTRATION SYSTEM 
PREPARES INITIAL RIP L.090 
& ASSIGNS NUMBER 
TO APPLICATION 



DELETE 
DOCUMENT 
FROM 
REGISTRATION 
SYSTEM 



YES 



306 



NO. 



'CHECK IF DOC* 
.PUBLISHED. 



REQUEST SENT TO TRACKING 
PROCESS VIA FTP 



-292 




296 



TRACKING SYSTEM 
SENDS MESSAGE 
TO 

REGISTRATION 
SYSTEM 



TRACKING SYSTEM SENDS 
OK TO REGISTRATION SYSTEM 
& PLACES RIP IN DATABASE 



I 



-302 



REGISTRATION SYSTEM 
PLACES APPLICATION 
IN EXAMINER'S QUEUE 



FIGURE 13 | 



-304 



FIG. 12 



SUBSTITUTE SHEET (RULE 26) 



WO 97/43717 



PCT/US97/07834 



1 1/28 



I 



306 

( 



EXAMINER'S VIEWS DOCUMENT & 
ADDS NAME & CLASS TO APPLICATION 




318 
1 



"REJECTION" MESSAGE 
SENT TO APPLICANT 



"APPROVED" MESSAGE SENT 
TO REGISTRATION SYSTEM 



± 



REGISTRATION SYSTEM ASSIGNS 
REGISTRATION NUMBER 



312 
1 



REGISTRATION SYSTEM CREATES, 
SIGNS & ARCHIVES CERTIFICATE 



I 



-314 



CERTIFICATE SENT VIA PEM 
TOUA 



-316 



UPDATED RIP SENT 
TO TRACKING SYSTEM 



-320 



COINS ADDS UPDATED RIP 
TO DATABASE & SENDS 

CONFIRMATION TO 
REGISTRATION SYSTEM 



I 



-322 



REGISTRATION SYSTEM MOVES 
APPLICATION TO CATALOG 
QUEUE 



I 



-324 



CATALOGER CREATES CATALOG 
INFORMATION WITH 
CATALOGING SYSTEM 



I 



—326 



CATALOGER SENDS CONFIRMATION 
TO REGISTRATION SYSTEM 



T 



-328 



FIG. 13 



REGISTRATION SYSTEM RECORDS 
"PROCESSING COMPLETE" IN LOG 



-330 



SUBSTITUTE SHEET (ftULE 26) 



WO 97/43717 



12/28 



42 



WORKSTATION 



« — 



FILE 
SERVER 



DOC 



34 

_L 



r 



DOC 



DIG SIG 



PUB KEY 
CAT 



UA 



PEM 
MIME 



RIGHTS 
MANAGEMENT 
SYSTEM 



REPOSITORY —36 



43 




FIG. 14 



SUBSTITUTE SHEET (RULE 2$ 



WO 97/43717 



PCT/US97/07834 



13/28 



USER MAKES OBJECT 
AVAILABLE TO UA 



—350 



UA SENDS HANDLE 
REQUEST TO HANDLE 
GENERATOR SYSTEM 



I 



—352 



HANDLE GENERATOR 
RETURNS HANDLE 



I 



-354 



UA SIGNS & SENDS 
REQUEST VIA 
PEM TO RMS 



—356 




360 
_L_ 



RMS SENDS 
"INVALID" MESSAGE 
TO UA & DISCARDS 
REQUEST 



RMS STORES HANDLE 
& ASSOCIATED TERMS 



I 



—366 



RMS SENDS 

CONFIRMATION H 368 
TOUA 



FIGURE 16 1 



FIG. 15 



SUBSTITUTE SHEET (RULE 26) 



WO 97/43717 



14/28 



PCT/US97/07834 



FIGURE 15| 



UA COMPUTES OBJECT'S 
DIGITAL SIGNATURE OVER 
HANDLE, GROUP & OBJECT 



I 



-370 



UA SIGNS & SENDS REQUEST 
VIA PEM/MIME TO REPOSITORY 



-372 



376 
1 



REPOSITROY 
SENDS 
MESSAGE TO UA 
& DISCARDS REQUEST 




REPOSITORY STORES 
OBJECT & INFORMATION 



I 



-388 



REPOSITORY COMPUTES 
DIGITAL SIGNATURE OVER 
HANDLE, GROUP & OBJECT 



I 



390 



REPOSITORY SENDS 
CONFIRMATION VIA —392 
PEM TO UA 1 

1 



FIG. 16 



SUBSTITUTE SHEET (RUl£ 26) 



WO 97/43717 



PCT/US97/07834 



| FIGURE 16 1 



15/28 



UA VERIFIES REPOSITORY'S 
DIGITAL SIGNATURE OVER HANDLE 
GROUP & OBJECT 



T 



394 



UA STORES HANDLE, OBJECT & 3 q 6 
REPOSITORY INFORMATION T Jat> 

I 



UA COMPUTES OBJECT 
HANDLE HASH 



I 



398 



CUA LOOKS UP HANDLE SERVER 
RESPONSIBLE FOR HANDLE 
IN HASH TABLE 



—400 



I 



CUA SIGNS & SENDS MESSAGE 
TO HANDLE SERVER VIA PEM 



—402 



408 



UA READS NEW 
HASH TABLE FROM 
HANDLE SERVER 
DIRECTORY 



404 

HANDLE " 
JSERVER RESPONSIBLE 
.FOR HANDLE 

? 



NO 



I 



406 



HANDLE SERVER 
SENDS MESSAGE 
TO VA & DISCARDS 
MESSAGE 



rYES 



410 



DIGITAL 
SIGNATURE VALID 
.OVER MESSAGE. 
? 

Tyes 

414 

HANDLE" 
SERVER ACCEPTS 
.MESSAGES FROM 
CUA ? 



r 



412 



YES 



416 



.SYNTAX CORRECT- 
? 

Tyes 



.NO 


HANDLE SERVER 
SENDS "INVALID" 


>— ■ — ; »> 


MESSAGE TO UA & 
DISCARDS MESSAGE 




i 


i 


«^NO 










L 


NO 







HANDLE SERVER STORES A . 0 
HANDLE INFORMATION h 418 
FROM UA'S MESSAGE 



I 



FIG. 17 



HANDLE SERVER SENDS 
CONFIRMATION TO UA 



—420 



SUBSTITUTE SHEET (RULE 26) 



WO 97/43717 



PCT/US97/07834 



16/28 





(O 


TRACKING 
SYSTEM 










[—40 


f 

1 
/ 
/ 
/ 
/ 




00 

O 

LL 



SUBSTITUTE SHEET (RULE 26) 



WO 97/43717 



PCT/US97/07834 



17/28 



APPLICANT GENERATES 
DIGITAL SIGNATURE 
FOR DOCUMENT 



—450 



APPLICANT MAKES SIGNATURE 
AND PUBLIC KEY CERTIFICATE 
CHAIN AVAILABLE TO UA 



— 452 



UA FILLS OUT APPLICATION 
FORM & SIGNS IT 



— 454 



UA SIGNS & SENDS REQUEST TO 
REGISTRATION SYSTEM VIA 
PEM/MIME 



—456 



REGISTRATION SYSTEM RECORDS 
REQUEST RECEIPT IN LOG 



-458 



462 
_L_ 



REGISTRATION 
SYSTEM SENDS 

MESSAGE TO 
CUA & RECORDS 
FAILURE IN LOG 




REGISTRATION RECORDS 
APPLICATION INFORMATION 
IN DATABASE & LOG 



r-470 



FIGURE 20 



FIG. 19 



SUBSTITUTE SHEET (RULE 26) 



WO 97/43717 



PCT/LS97/07834 



18/28 



FIGURE 19 



I 



REGISTRATION SYSTEM 
COMPUTES DOCUMENT 
HANDLE HASH 



— 472 



LOOK UP HANDLE SERVER 
IN HASH TABLE 



— 474 



REGISTRATION SYSTEM SENDS 1-476 
POINTER REQUEST TO 
HANDLE SERVER 




REGISTRATION SYSTEM 
RELOADS HASH TABLE 
FROM HANDLE SERVER 
DIRECTORY 



—482 



HANDLE SERVER 
SENDS ERROR 
MESSAGE TO 
REGISTRATION 
SYSTEM 



—480 



HANDLE SERVER 
SENDS ERROR MESSAGE 
TO REGISTRATION SYSTEM 



HANDLE SERVER 
RETURNS POINTERS 
TO REGISTRATION SYSTEM 



-492 



-486 



REGISTRATION SYSTEM 
SENDS MESSAGE TO CUA 



FIGURE 21 



—488 



REGISTRATION SYSTEM 
REMOVES INFORMATION 
FROM DATABASE & 
RECORDS FAILURE 
IN LOG 



—490 



FIG. 20 



SUBSTITUTE SHEET (RULE 26) 



WO 97/43717 



PCT/US97/07834 



19/28 




YES 



REGISTRATION 
SYSTEM CONNECTS 
TO RMS 



I 



h-500 



502 



RMS RETURNS 
RANDOM VALUE TAG 
TO REGISTRATION SYSTEM 



T 



REGISTRATION SYSTEM 
SENDS INFORMATION 
TO RMS 



— 504 



RMS SENDS 
ERROR MESSAGE 
TO REGISTRATION 
SYSEM 



REGISTRAT 



ON SYSTEM 



LOGS ERROR & REMOVES 
APPLICATION INFORMATION 
FROM DATABASE 




RMS CONNECTS 
TO REPOSITORY 



— 510 



REPOSITORY 
RETURNS TAG 
TO RMS 



FIG. 21 



I 



-512 



514 



RMS SENDS INFORMATION 
TO REPOSITORY 



FIGURE 22 



SUBSTITUTE SHEET (RULE 26) 



WO 97/43717 



PCT/US97/07834 



FIGURE 21 1 



20/28 



516 

"DIGITAL" 
SIGNATURE OF 
JRMS VALID OVER. 
TAG? 



NO 



|YES 



524 



RMS 

ALLOWED TO TRANSFER^ 
DOCUMENT 

? 



NO 



REPOSITORY SENDS 
ERROR MESSAGE 
TO RMS 



1—518 



RMS LOGS ERROR & 
SENDS ERROR MESSAGE 
TO REGISTRATION SYSTEM 



YES 



REPOSITORY SENDS 
CONFIRMATION TO RMS 



I 



— 526 



REGISTRAT 



— 520 



ON SYSTEM 



LOGS ERROR & 
REMOVES INFORMATION 
FROM DATABASE 



— 522 



REPOSITORY DISCONNECTS 

FROM RMS l_528 



I 



RMS FORWARDS 
"RETRIEVAL ALLOWED" 

MESSAGE TO 
REGISTRATION SYSTEM 



I 



-530 



RMS DISCONNECTS FROM 
REGISTRATION SYSTEM 



— 532 



REPOSITORY CONNECTS TO 
REGISTRATION SYSTEM AND 
TRANSMITS HANDLE & 
SIGNED DOCUMENT 



— 534 



I 



REPOSITORY SENDS 
CONFIRMATION TO RMS 



-536 



REGISTRATION SYSTEM 
RECORDS ERROR IN 
LOG & REOMOVES 
INFORMATION FROM 
DATABASE 



538 

"APPLICANTS" 
SIGNATURE VAUD OVEF 
DOCUMENT 

? 

*YES 



I 



-542 



REGISTRATION 
SYSTEM SENDS 
ERROR MESSAGE 
TOUA 



— 540 



HANDLE PLACED 
IN ACQUISITION QUEUE h~544 



I 



I FIGURE 20, STEP X| 

SUBSTITUTE SHEET (RULE 26) 



FIG. 22 



WO 97/43717 PCT/US97/07834 



21/28 




FIG. 23 



SUBSTITUTE SHEET (RULE 26) 



WO 97/43717 



PCIYUS97/07834 



22/28 



SET-Up5?B\JaCCOUNT^-706 
MESSAGE 



SIGN AND SEND 
MESSAGE TO 
PAYMENT SERVER 



—708 



•710 

_ 'payment' 
server verifies 
signature^ 



INVALID 



SEND 
MESSAGE 



—712 



I VALID 



-714 



CREDIT 
VERIFICATION 



INVALID 



SEND 
MESSAGE 



-716 



[VALID 



-718 



CREDIT LIMIT 
CHECK 



TOO 
HIGH, 



SEND 
MESSAGE 



—720 



722 



CHECK USER 
ID'S 



INVALID 


SEND 




MESSAGE 



— 724 



ASSIGN ACCOUNT L-726 
NUMBER A STORE 



T 



FORMAT AND SEND L-728 
NEW ACCOUNT MESSAGE r 



STORE NEW ACCOUNT 
INFORMATION 



— 730 



FIG. 24 



SUBSTITUTE SHEET (RULE 26) 



WO 97/43717 



23/28 



PCTVUS97/D7834 



RETRIEVE TABLE |— 740 



OBTAIN A HANDLE | — 742 
+ ^7 46 



HASH HANDLE AND 
PERFORM TABL E LOOKUP 

F 



SEND POINTER REQUEST] — 748 



750 

HANDLE ^| RR0R 

Server verifies hash 

RANGE 



756 



VERIFY HANDLE" 
PRESENT, 



752 
_J_ 



SEND 
MESSAGE 



754 



REFRESH 
TABLE 





758 

f 




760 


NO 


SEND 




INFORM 




MESSAGE 


— ► 


USER 



_ . 762 

USE 

'OINTERS TO GET 
OBJECT 



SEND MESSAGE , 
IF UNSUCCESSFUL h~ 764 



CONNECT TO 
REPOSITORY 




— 766 



YES 



—770 



-772 



ERIFy 
^SIGNATURE. 



774 



DISCONNECT} — 768 



-778 

VERIFY" „ 
PAYMENT SERVER 
SIGNATURE 



INCORRECT 


SEND 




MESSAGE 


JNCORRECT 




SEND 




MESSAGE 



-776 



—780 



(continue) FIG. 25 

SUBSTITUTE SHEET (RULE 26) 



WO 97/43717 



PC17US97/07834 



24/28 



REPOSITORY RETRIEVES 
TERMS AND CONDITIONS 



± 



-790 



REPOSITORY SIGNS AND SENDS 
TERMS AND CONDITIONS 



I 



J- 792 



REQUESTING SYSTEM ^ A 
VERIFIES SIGANTURE ~ 794 



I 



IUSER SELECTS TERMS I — 796 



REQUESTING SYSTEM 
CREATES/SIGNS/SENDS 
MESSAGE 



—798 



800 

lEPOSITOR\ 
VERIFIES SIGNATURE 



INCORRECT 


802 

I 


SEND 


> » 


MESSAGE 



R E PO SI TORYESTA^ISHCONN E CTION[ _ g04 



I 



PAYMENT SERVER RETURNS 
RANDO N-VALUE TAG 



h 



806 



REPOSM'ORY FORMS/SIGNS/SENDS I „ n o 
DEBIT ACCOUNT MESSAGE I "" 808 



PAYMENT SERVER I om 
VALIDATES SIGNATU RE]- 8 ™ 

812 



± 



w PAYMENT SERVER \ 
VALIDATES SIGNATURE [ ~ 



I 



PAYMENT SERVER VERIFIES I 
ACCOUNT ACCESS RIGHT | ~ 



814 



I 



PAYMENT SERVER VERIFIES THATL-ft-tfi 
AMOUNT MAY BE CHARGED [ ~~ 816 

PAYMENT SERVER SIGNS AND SENDS I 



DEBIT MESSAGE 



818 



r TOSI & s i N E?c 0BjECT f «2Q 

SUBSTITUTE SHEET (RULE 26) 



FIG. 26 



W0 97/437,? PCTVUS97/07834 

25/28 

REQUESTING SYSTE-M CONNECTS TO RT^Sl- 830 

RMS RETURNS RANDOM- VALUE TAGl— 832 

* 

fRMS SENDS INFORMATION 1 -834 

fR^ISVATIDATls SlGNAtUft-EV 836 

KtKUbl lORY VERIFIES PAYMENT I 838 
SERVER'S SIGNATURE h 838 



i RMS/USER DIALOG M ^O 
|RMl? CONNgCTS^TQ REPOSITORY^ 842 

[REPOSITORY RETURNS RANDOM TAG VALUE 1 -844 

I RMS SENDS INFORMATION} — 846 

I REPOSITORY VERIFIES SIGNATURFU 84R 
i 

REPOSITORY CONNECTS TO PAYMENTS"SER\7fr T— fififl 
I PAYMENT SERVER RETURNS RANDOM VA LUE TAG 1- 852 



REPOSITORY CREATES^SIGNS AND SENDS I 

DEBIT ACCOUNTS MESSAGE ' h 854 

i 1 



1 PAYMENT SERVER VALIDATES SIGNATURE! -- 856 

I 

I PAYMENT SERVER VERIFIES ACCOUNT RIG HTS 1—858 

1 ' 

LAMENT SERVER VERIFIES CHARGE AMOUNT U 860 
• I 

1 PAYMENT S ERVER SENDS ACCOUNT DEBIT MESSAfi F U 862 

. + ; J 

I orr J?£F,9? ,T0RY RETURNS IftfU 

I RETRIEVAL ALLOW ED MESSAGE H 864 

ir ~ 

I RMS FORWARD MESSAGEl — 866 

* 

[REPOSITORY SENDS OBJECfTETOV - 868 

REPOSITORY SENDS DELIVERY CQNRRMTIonV 870 

FIG. 27 

SUBSTITUTE SHEET (RULE 26) 



WO 97/43717 



PCT/US97/07834 



26/28 



r 



1102 



REPOSITORY 



1108 



NAME 



1122 



STORED 
DIGITAL OBJECT 



1124 



REGISTERED 
DIGITAL OBJECT 



1104 



REPOSITORY 



1110 



NAME 



1106 



REPOSITORY 



1112 



NAME 



1114 



GLOBAL NAMING MECHANISM 



GLOBAL NAMING AUTHORiTYl 



r 



1115 



: NAMES 
,1116 i 


GLOBAL 
NAMING 
MECHANISM 


|LOCAL NAMING AUTHORITY | 


^-1117 

LOCAL 
NAMING 
MECHANISM 


,1118 


LOCAL NAMING AUTHORITY | 


,1120 




lLOCAL NAMING AUTHORITY | 





\ 



V- HANDLES 
\ 1127 



1128 



HANDLE 
SERVER SYSTEM! 



FIG. 28 



SUBSTITUTE SHEET (RULE 26) 



WO 97/43717 PCT/US97/07834 

27/28 



1132 



DIGITAL OBJECT 
HANDLE TYPE 



FIG. 29 



DIGITAL OBJECT 
TYPE 


1130 

1 , 


DIGITAL OBJECT 


TYPE 


1134 



1140 



1142 



ORIGINATOR 
DIGITAL OBJECTS 



— — fr. 


HANDLE 






SYSTEM 


4 



TERMS & 
CONDITIONS 



—1144 



FIG. 30 



REPOSITORY 



1136 



RAP 



REQUEST 



± 



J 



NAMING 
AUTHORITIES 



HANDLE, 
SERVICE REQUEST TYPE, 
PARAMATERS ' 



1138 

-_L_ 



DISSEMINATION 



SERVICE R EQUEST PROGRAM [— 1 150 



METADATA REQUEST}- 1 152 

r — 



RAP 
1136 



KEY-METADATA REQUESfL- 1 154 

j— • 



DIGITAL OBJECT REQUEST] — 1 1 56 



I 



DATA-TYPE-DEPENDENT REQUEST | 1 157 



SYSTEMS LEVEL SERVICESi— 1 158 



DISSEMINATION 
KEY-METADATA 
HANDLE 

• • • 



FIG. 31 



SUBSTITUTE SHEET (RULE 26) 



WO 97/43717 



PCT/US97/07834 



1200 



1204 
1 



NAME OF LOCAL 
NAMING AUTHORITY 



28/28 



1202 
__L_ 



SEPARATOR 



1206 
1 



LOCALLY 
UNIQUE STRING 



1208 
1 



INDIRECT 
HANDLE 



FIG. 32 



| naming authority n] 1210 

Isuper-administratorT j 12 
ilower order naming authorityh j 

IPERMISSIONsV -1214 / 

\ I HANDLE GENERATOR L -1??n 



1216 

GLOBAL HANDLE SERVER~g1 



PR MARY HANDLE 
SERVER P HANDLES 
INDIRECT HANDLES 



I ORIGINATOrV -1999 



FIG. 33 



HANDLE SERVER SYSTEM ^1230 



IhANDLE SERVERS|-1232 


r 1234 


Idistributed global handle server g I 


HANDLE DIRECTORY! 


IHANDLE RECORDS|-1236 


SERVERS | 


. lLOCAL SERVER HANDLES |- 1238 


TABLE OF NETWORK I 
ADDRESSES 



CLIENT 
LIBRARY 

OF 
ROUTINES 



M244 



NAMING AUTHORITY HANDLES^ — 1240 







| LOCAL HANDLE SERYER(S) I 




r ^242 

CACHING SERVERS h * 




r J 1246 


CLIENTS C | 


PROXY SERVER |< — J 


CLIENTS C | 



FIG. 34 



SUBSTITUTE SHEET (RULE 26J 



INTERNATIONAL SEARCH REPORT 



International application No. 
PCT/US97/07834 



A. CLASSIFICATION OF SUBJECT MATTER 
IPC(6) :G06F 13/00 

US CL :395/610, 616, 677; 3W/4, 25 
According to Intc roational Patent Clarification (IPC) or to both national edificatio n and IPC 

B. FIELDS SEARCHED~~ " !" ~ ' 



Minimum documentation searched (classification system followed by classification symbols) 
U.S. : 395/616, 610, 677; 380/4, 25 



Documentation searched other than minimum documentation to the extent that such document, are included in the fields searched 
None 



Electronic data base consulted during the international search (name of data base and, where practicable 
APS 



search terms used) 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category* 



Citation of document, with indication, where appropriate, of the relevant 



passages 



Relevant to claim No. 



US 5,260,999 A (WYMAN) 09 November 1993 

col. 1, lines 27-60, 

col. 2, lines 35-52, 

col. 1 1 , lines 3-30, 

col. 21, lines 22-45, 

col. 36, line 64 - col. 37 line 23. and 

Abstract 

US 5,321,841 A (EAST et al) 14 June 1994. 

col. 1 , lines 26-30, 

col. 1 , line 66 - col. 2, line 3, 

col. 4, line 1-23, 

col. 22, line 58 - col. 23, line 4, 

col. 32. lines 11-63. 

col. 33. lines 33-42. 

col. 34. lines 8-17, and 

col. 36, lines 3-54. 



1-7, 12-18. 36 
40 



2-3, 5, 8-10, 
19-35, 41-50 



JCj Further document! ere listed in the continuation of Box C. Q See patent family 



Specie! cMegorieo of died donuMob: 

docemaiideflolii, Dm ,eacnl «* rf art which h ■ 
io he of puocuk, rekvue* 

daamml which euy thraw doubu oo priority clun*) o, «luch a 

surest %L£t^ . r 

JjJJ* ttlmkt *mtnl dteloaae. ate. eihftWoo or «her 



dogma* of pwticmW relevance; the ckumed bvtniwc cuoot be 
wbca toe dmrmfnt m fckm tlooc ^ 



I to nvoive u toveeuve Me, wheo fee doca— ul m 



beto* abviam to a pnoa ■killed to Sm ut 
dm wii tofber of toe to— plmt funily 



Date of the actual completion of the international search 
21 JULY 1997 



Name and mailing address of the ISA/US 
Commissioner ofPsientA and Trademsitf 
Box PCT 

Wtahington, D.C. 2023 1 
Facsimile No. (703) 305-3130 



Form PCI71SA/210 (second aheet)(iuly 1992)* 



Date of mailing of the international search report 

t ^310CT1997 




/ THOMAS LEE 
Telephone No. (703) 305*9717 



INTERNATIONAL SEARCH REPORT 



International application No. 
PCT/US97/07834 



C (Continuation). DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 11 



Citation of document, with indication, where appropriate, or the relevant passages 



Relevant to claim No. 



US 5,491,817 A (GOPAL et al) 13 February 1996, 
col, 1, lines 37-55, 
col. 2, lines 23-31, and 
col. 8, lines 6-67, 



US 5,222,134 A (WAITE et al) 22 June 1993, 
col, 2, lines 13-44, 
col. 5, lines 17-22. and 
Abstract. 



1, 4, 7-28, 32- 
38, 46-50 



l f 6, 11-16, 29- 
31, 39-45 



Form PCTASA/210 (continuation of second shect){July 1992)* 



^Page 



BlQnk (uspt 0) 



